On Wed, 20 Jan 2021 03:19:19 GMT, Frank Kotler
<fbkotler@nospicedham.myfairpoint.net> wrote:

I'll try (again) to find that example,

https://forum.nasm.us/index.php?topic=2656.msg11959#msg11959

Not a tutorial.

Best,
Frank

Sounds like someone else is trying nasm under W10:

https://forum.nasm.us/index.php?topic=2396.0

--
Bah, and indeed, Humbug.

On 20.01.2021 06:00, paul wrote:

I apologize if I didn't know enough to ask the right question.

If you think a simple tutorial can teach you assembly programing,
then maybe are misunderstanding something. There are 3 parts of
assembly programming:

1. Writing a sequence of CPU instructions.

Just scroll through the first part of the instruction manual:

https://www.intel.de/content/www/de/de/architecture-and-technology/64-ia-32-architectures-software-developer-vol-2a-manual.html

and then decide again if you want to write a sequence of these
instructions.


2. Communicating with the operating system.

Spend a few weeks on:

https://docs.microsoft.com/en-us/windows/win32/api/

and the decide again if you really want to use a low
level interface to the OS.


3. Put 1+2 in a format (exe file format), so that the OS can load
and start your sequence of CPU instructions and is able to
execute the OS calls. This is normally done by the assembler
and linker, but an assembly programmer should know whats the
purpose of each byte in the exe file.


If you still want to start with assembly programming, here a
very simple demo program. Shouldn't be a problem to convert it
to the syntax of your preferred assembler, because it's mostly
only byte declarations and a few CPU instructions, starting at
Winmain:. No liker needed, all is done manually in the assembler
source.


                                         ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
                                         ;; MINI.mac: display a message box                                ;;
                                         ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

                                         UseIdatSection=0 ; 0 if no idat section is used
                                         UseUdatSection=0 ; 0 if no udat section is used

                                         ;#==================================================================#
                                         ;#                    Start of Headers                              #
                                         ;#==================================================================#

                                         ;       +--------------------------------------------+
                                         ;       |         Start of DOS Header                |
                                         ;       +--------------------------------------------+

                                                                         ; DOS .EXE header
00000000: 00000000: 4d 5a                       dc.b    'MZ'            ; Magic number
00000002: 00000002: 0160                        dc.w    dosfilesize\512 ; Bytes on last page of file (0->512)
00000004: 00000004: 0001                        dc.w    (dosfilesize-1)/512+1
                                                                         ; Pages in file (Page=512 byte)
00000006: 00000006: 0000                        dc.w    0               ; Relocations (nr of entries)
00000008: 00000008: 0004                        dc.w    doshead_end/16  ; Size of header size in paragraphs (16 byte)
0000000a: 0000000a: 0000                        dc.w    0               ; Minimum extra paragraphs needed
0000000c: 0000000c: ffff                        dc.w    $ffff           ; Maximum extra paragraphs needed
0000000e: 0000000e: 0000                        dc.w    0               ; Initial (relative) SS value (ss=load_adr+nr)
00000010: 00000010: 0160                        dc.w    dosstack        ; Initial SP value
00000012: 00000012: 0000                        dc.w    0               ; Checksum
00000014: 00000014: 0000                        dc.w    dosmain         ; Initial IP value
00000016: 00000016: 0000                        dc.w    0               ; Initial (relative) CS value (cs=load_adr+nr)
00000018: 00000018: 0040                        dc.w    reloc           ; File address of relocation table
0000001a: 0000001a: 0000                        dc.w    0               ; Overlay number
0000001c: 0000001c: 0000 0000 0000
00000022: 00000022: 0000                        dc.w    0,0,0,0         ; Reserved words
00000024: 00000024: 0000                        dc.w    0               ; OEM identifier (for e_oeminfo)
00000026: 00000026: 0000                        dc.w    0               ; OEM information; e_oemid specific
00000028: 00000028: 00000000 00000000
00000030: 00000030: 00000000 00000000
00000038: 00000038: 00000000                    dc.l    0,0,0,0,0       ; Reserved words
0000003c: 0000003c: 000000a0                    dc.l    WinHeader       ; File address of new exe header
                                         reloc:
                                         doshead_end:

                                                 @=$0
00000040: 00000000: 0e                  dosmain:move.w   s6,-(sp)
00000041: 00000001: 1f                          move.w   (sp)+,s0
00000042: 00000002: ba 000e                     move.w   #_text,r1
00000045: 00000005: b4 09                       move.b   #$09,m0
00000047: 00000007: cd 21                       trap     #$21

Click here to read the complete article

Tavis Ormandy wrote:

I feel your frustration, but you're trying to jump in at the deep end
with native win64 assembly language.

When I asked the question originally, I had no idea it would be this hard.

I figured it would be like any freshman level physics lab.
1. You check out the equipment (e.g., a capacitance tester)
2. You grab a ziplock bag of pre-prepared capacitors of various types
3. You measure their capacitance, and write up a report

Notice that the lab is designed to work.
The student simply follows the steps.
The learning is in watching it work.

I don't want to design my own capacitor like Pieter van Musschenbroek did.
I'm not building a competitive capacitor like Ewald Jurgen von Kleist did.
I'm not breaking any new ground in capacitor design like William Watson did.

I just want to learn about capacitors by running a simple lab.
Like any freshman physics student would.

I just want to learn about assembly language by running a simple tutorial.

This is just opinion, but I think
starting with C or C++ would be a better option. If you want to learn
assembly as you go, you can examine the code the compiler generates and
try to follow along with what it's doing.

The reason I dropped the comp sci curriculum was syntax, where every
language does the same damn thing using completely different syntax.

For example, Fortran's trenchant yet precise syntax resulted in a terse
"Error 50", which you had to look up in a book in the computer room locked
down to a table with half the pages missing. On the opposite side of the
spectrum, COBOL was downright loquacious, with bombastic divisions and gabby
data types. Somewhere in between was PL/1 but my point is they all do the
same damn thing, but with completely different syntax.

I swore I'd never learn another programming language in the early seventies,
and I stuck to my word, and even now, I don't want to learn assembly
language just like I don't want to learn how to design a microprocessor.

Suffice to know that CPUs boot from a specific memory location in ROM where
temporary storage is in RAM, and that registers are used to push, pull and
pop stuff off the stack, etc.

You can get all that knowledge WITHOUT designing your own CPU, as a "lab" of
sorts, where all you do is watch it happen on simple code:
 Load Accumulator A with the data in memory location 1
 Load Accumulator B with the data in memory location 2
 Add Accumulator A and Accumulator B & call printf to display the result

I don't want to write my own assembly language programs.
I just want to watch it happen which is why I seek a tutorial.
But a tutorial that doesn't work is a worthless tutorial in my humble
opinion as I'm not on strange equipment (Windows 10 x64).

I'm on the most common home equipment there is.
So there MUST be a tutorial that walks me through a bunch of hello worlds.

Even PL/1 syntax drove me nuts, although Fortran took the cake in terseness
what with looking up the errors by number ("Error 42" was all you got) in a
book the size of the Gutenberg Bible.

One fun tool you can look at is compiler explorer, take a look:
https://godbolt.org/z/WW3383

I looked at https://godbolt.org/z/WW3383 which does seem like a fun tool in
that you put your "hello world" c code at left, and it creates the assembly
language code at the right.

In my not too distant past, I had, like everyone did, all the SAMS books,
along with the blue & white teach yourself c in 21 days little handbook,
where I toyed with C just as I want to toy a bit with assembly code today.
I'm sure it's still on my shelves in my office. It's right next to my Carver
Mead/Lynn Conway book on designing what they called "VLSI" IC's from the
late 70's early 80's time frame (where we literally laid out designs in
graduate school using stick diagrams and colorful pencils, green for
diffusion, red for poly, and blue for metal (it was two layers of metal so
we needed dark blue for metal 2).

The problem with that page, while fun, is that it turns into the complexity
of a finfet within moments, once you push into it any reasonably sized c
code (even if only a handful of lines) as it will pop out the compiled
assembly language which will have all sorts of complexities almost
instantaneously.

It's as if I asked you to design a chip to turn a light bulb on at 3am every
morning. The task is simple but the chip design can be done ten thousand
different ways to accomplish the exact same simple task, none of which will
make much sense given how capricious the resulting design can be.

Still, it does look like fun, where I looked for a "c++ lab" to simply add
the value stored in accumulator A to that which is stored in accumulator B
and to output the result.

You write some C on the left, and it shows you nicely formatted
assembly on the right. You can try changing something, and watch what
happens to the generated code.

As I said, I looked for the "lab" to just add what's in two registers,
where, to "create my own lab" for that web page (which I never wanted to
do!), I downloaded the SAMS "teach yourself C++ in 21 days" fifth edition at
http://openstorage.gunadarma.ac.id/pub/journal/Teach%20Yourself%20C++%20in%2021%20Days%205th%20Edition.pdf

I found this on page 73 of that PDF:
 int myAge = 5;
 int temp;
 temp = myAge + 2 // add 5 + 2 and put it in temp
 myAge = temp // put it back in myAge
Which they then shortened on page 74 to:
 myAge = myAge + 2;  // myAge +=2

So I popped that last line into the fun c-code-to-assembly language page
with the result of "<Compilation failed>", which is my whole point about
designing my own capacitor.

I added back the boilerplate syntax (reminiscent of COBOL back in the day,
where every program STARTED with a hundred lines of boilerplate!),
  #include <stdio.h>
  int main()
  {}

That boilerplate resulted in this assembly language code:
  main:
  xor eax, eax
  ret
Which, seems odd to me that a boolean operation that always returns FALSE
would be the result, but hey, I didn't write the code explorer - I'm just
testing it (someone is going to have to explain that one to me!). :)

Of course, adding just this line in between braces results in a failed
compilation:
  #include <stdio.h>
  int main()
  {myAge=myAge+2}

So now I have to play the silly COBOL syntax game of defining everything
that I never wanted to define in the first place, which, of course, had I
read the first 75 pages of the PDF I'm sure will tell me how, but the point
is that a freshman physics capacitance lab doesn't spend 75 pages to first
teach you how to design your own dialectic materials - you simply test out
WORKING dielectrics and learn empirically (if I had wanted to be Joseph
Faraday, that would be a different story).

Just wanting to test the capacitors (i.e., add two numbers), I skim about
adding semicolons and braces to satisfy the syntax requirements to get rid
of the "compilation failed" errors, and after skimming for syntax examples
in the PDF, I piece together a Frankenstein set of C++ code that simply adds
two to a variable:
  #include <stdio.h>
  int main()
  {int myAge;
  myAge = myAge + 2;
  }

Which returns, surprise!
  main:
   xor eax, eax
   ret

There is no "compilation error", but it says "Compiler returned: 0",
which, I guess, maybe, perhaps, I dunno, is that an error or did it work?

Anyway, if I already knew C++, this might be fun. But I not know C++ and far
worse, I'm allergic to higher level programming languages all doing exactly
the same thing in a billion different ways (just so they can claim to be
different).

In this test of the "fun code", I just wanted to add two numbers in assembly
language by cutting and pasting them from a tutorial that is written like a
freshman physics labs on capacitance.

But I'm writing my own tutorial.
And that's NOT what I had wanted to do.
It's not fun at all.

What's fun is grabbing a bag of colorful tantalum, electrolytic, film, mica,
polymer, vacuum, polarized, pancake, and variable capacitors and testing
their capacitance with the capacitance meter hooked up both ways to the
leads, and writing down the results, like any good lab (aka tutorial) should
do.

In short I just want an assembly language tutorial that anyone would want
(I'm not special). It should assume I'm on the most common home computing
platform on they planet (no surprises there!) and it should tell me where to
download the installer and then it should have me cut and paste the first,
second, third, fourth, and fifth assembly language program which should just
work.

Once I have a half dozen assembly language programs that just work, then I
have already learned what I want to learn. If it's still fun, then I do the
next dozen. And if it's really fun, I even go off road and try to experiment
with them, but if they don't work, I can back up to the last working example

Click here to read the complete article

Herbert Kleebauer wrote:

If you think a simple tutorial can teach you assembly programing,
then maybe are misunderstanding something. There are 3 parts of
assembly programming:

I wasn't clear in my opening post if I said I wanted to "learn" assembly
language programming.

Just as a person can hike an existing trail that someone else dug out and
put all the steps and bridges and maps in place years before, I just want to
"walk the trail" of an existing assembly language programming tutorial.

If I had wanted to build my own trail, cutting steps in the snow, attaching
belay lines across the Hillary Step, staking down ladders across the Khombu
Icefall, designing my own oxygen cylinder breathing apparatus, designing my
own insulating clothing, testing out the chemicals for the rubber soles of
my boots, designing my own shoe laces, etc., I would have started with my
existing books by Peter Norton & Jeff Duntemann on Assembly Language
Programming, step by step.

I don't want to build the trail - I just want to follow the existing trail.

I'm not Lewis & Clark, where I have to build my own bridges and dig out my
own canoes just to figure out what's at the end of a river, where if I don't
portage across the waterfall, I'm dead (that's no fun).

I apologize that I wasn't clear in the opening post because I was under an
illusion that there existed an assembly language tutorial (much like the
Android Studio tutorial that exists) which simply walks you though the
steps, so that in an hour or two, you've already got a half dozen programs
working.

It's fun to follow a trail that someone else already built, but if I have to
chop down a tree to build my own canoe just to get across to the other side
of the river, then it's no fun anymore.

When I get to the other side of the river, I will find that there is no
trail, and worse, all there is on the other side is a never ending swamp of
bog after bog, which is "no fun".

Fun is a trail to get you to the river, and then a bridge to get across the
river, and then on the other side, someone put down duckboard to get across
the swamp, where they already knew the shortest way through the swamp to get
to the flowers that are growing at the piedmont.

Fun is an assembly language tutorial to get you across the river of
installing and assembling your first program, and then across the swamp of a
few examples, so that in an hour or two, you already have a half dozen
assembly language programs working.

After that, if you still want to step off into the peat bog, if you think
that's fun, you can do it - knowing that you can back up if you step into
quicksand, and you'll be back on the working duckboards.

Back to the original need, I will endeavor to find a tutorial that works on
the most common computer platform in the world, using whatever assembler
that tutorial suggests.

On 2021-01-20, paul <nospam@nospicedham.nospam.invalid> wrote:

Which, seems odd to me that a boolean operation that always returns FALSE
would be the result, but hey, I didn't write the code explorer - I'm just
testing it (someone is going to have to explain that one to me!). :)

To make different pieces of code work together, all the code has to
follow certain rules - called calling conventions. You don't *have* to
follow those rules, but it means your code will work well with others.

One of those conventions is to put the return code (the result) in the
eax register. So in this case, that's just letting other code know
everything was okay.

Which returns, surprise!
  main:
   xor eax, eax
   ret

There is no "compilation error", but it says "Compiler returned: 0",
which, I guess, maybe, perhaps, I dunno, is that an error or did it work?

It worked, but compilers are smart - it knew that you didn't use the
result of the computation, and so it didn't matter if it did it or not.
That means it can generate a program that does exactly the same thing
but *faster* by not doing it at all.

There are a ton of these you'll notice, some are really confusing when
you first run into them. I think I was fascinated by that, understanding
things like strength reduction (that's where the compiler replaces
expensive operations like multiplication with equivalent cheaper ones
like shifts and adds) - but if you think you'll be frustrated by it,
maybe this won't work.

It's what everyone would want who is a noob who just wants a working set of
examples (aka a tutorial) on the most common computer platform there ever
was.

I don't know if there is a good answer. If you want to skip the
introductory classes, you can't complain that you have to work harder to
catch up :)

Tavis.

--
 _o)            $ lynx lock.cmpxchg8b.com
 /\\  _o)  _o)  $ finger taviso@sdf.org
_\_V _( ) _( )  @taviso

On Wed, 20 Jan 2021 13:04:01 GMT, paul
<nospam@nospicedham.nospam.invalid> wrote:
[]

Back to the original need, I will endeavor to find a tutorial that
works on the most common computer platform in the world, using
whatever assembler that tutorial suggests.

Sorry we couldn't help; x86 is ancient technology that requires a lot of
effort to get into. I doubt there's much impetus to create a slick modern
streamlined tutorial.




--
Bah, and indeed, Humbug.

On 20.01.2021 14:04, paul wrote:

Just as a person can hike an existing trail that someone else dug out and
put all the steps and bridges and maps in place years before, I just want to
"walk the trail" of an existing assembly language programming tutorial.

I suppose, you are joking. It's like asking for a tutorial to write
a German novel, but refusing to first learn the German language. You
don't need instructions how to put an empty sheet of paper into the
typewriter and how to transfer letters to the paper as long as you
don't understand the language you want to use for your novel. But
if you refuse to learn German, you can write the novel in English and
use Google to translate it to German.

So, start to read the few thousands pages of documentation I gave you.
And once you have understood them, you can start to read the additional
10 pages how to use the assembler to generate a binary from your source
code. But if you refuse to learn the assembly language and the OS interface,
you can write your code in any HLL and use an automatic translator to
convert it to assembly code (called compiler). But that has nothing
to do with assembly programming.

An other way to start assembly programming would be to not use an
x86 CPU and Windows 64 but a simple micro-controller with no
OS at all (like AVR). The instruction set is much simpler and there
is no OS interface to understand, so you can start programming after
a few hours reading the processor manual. And in this case you will
also find the sort of tutorial you want.

On Wednesday, January 20, 2021 at 2:13:32 PM UTC+1, paul wrote:

Just as a person can hike an existing trail that someone else dug out and
put all the steps and bridges and maps in place years before, I just want to
"walk the trail" of an existing assembly language programming tutorial.

€ASM with its macrolibraries might be the right "trail" for you.
Download and unzip "euroasm.zip",
copy "Hello world" source text from the yellow box at https://euroassembler..eu/eadoc/#HelloWorld
paste it to "hello.asm",
assemble and link with "euroasm hello.asm"
and try to run "Hello32.exe" and "Hello64.exe".
When it works, feel free to extend the source with instructions retrieved from tutorials enumerated at
https://euroassembler.eu/eadoc/links.htm#Tutorials

vitsoft

On Wed, 20 Jan 2021 14:04:01 +0100
paul <nospam@nospicedham.nospam.invalid> wrote:

Just as a person can hike an existing trail that someone else dug out
and put all the steps and bridges and maps in place years before, I
just want to "walk the trail" of an existing assembly language
programming tutorial.

So, you want a tutorial for which you can view the executing
x86 instructions via a debugger or disassembler or interpreter?

The really old way of doing this was to get some binary code and
disassemble it, looking up each instruction in the programmer's
reference manual, and mentally following along with what the code was
doing.

The next really old way of doing this was to get some binary code and
step through it in a debugger, dumping the registers as you went, while
looking up each instruction in the programmer's reference manual, and
mentally following along with what the code was doing.

I don't recall if there is any modern, in-browser, online website for
x86 code which does something like either of those.  Travis pointed you
to Mr. Godbolt's emulator.

You might want to run some emulator, like DOSBox or MAME/MESS or QEMU
or Bochs or one of numerous others, depending on what computer and
operating system you use, to boot up a 16-bit DOS machine, e.g.,
FreeDOS.  Then, experiment with DOS .com's, use DEBUG the debugger and
disassembler for DOS, and some assembler such as MASM or perhaps NASM.
NASM also comes with a disassembler.

https://www.freedos.org/
https://www.nasm.us/

https://www.dosbox.com/
https://www.mamedev.org/
http://bochs.sourceforge.net/
https://www.qemu.org/

--

On Wed, 20 Jan 2021 13:47:47 +0100
paul <nospam@nospicedham.nospam.invalid> wrote:

When I asked the question originally, I had no idea it would be this
hard.

I figured it would be like any freshman level physics lab.
1. You check out the equipment (e.g., a capacitance tester)
2. You grab a ziplock bag of pre-prepared capacitors of various types
3. You measure their capacitance, and write up a report

Notice that the lab is designed to work.
The student simply follows the steps.
The learning is in watching it work.

This is a return to the 8-bit microprocessors of the 1980's.  You're
jumping in after decades of microprocessor development.

It's a bit more like learning calculus.  There are centuries of
knowledge which came before you got to class.  You get to start at the
very beginning.  Lucky you.

The reason I dropped the comp sci curriculum was syntax, where every
language does the same damn thing using completely different syntax.

Just use C.  TIOBE's index shows that it has been at the top of the
programming language usage charts for decades. (I have to apologize to
wolfgang every time I say that.)  Although, C is a huge time suck to
learn as well, but it'll be around - or it's many derivatives which
dominate the TIOBE index - for a while at least.

https://www.tiobe.com/tiobe-index/

For example, Fortran's trenchant yet precise syntax resulted in a
terse "Error 50", which you had to look up in a book in the computer
room locked down to a table with half the pages missing.

FORTRAN was a horrible language.

On the
opposite side of the spectrum, COBOL was downright loquacious, with
bombastic divisions and gabby data types.

I never programmed in COBOL but have seen it IRL.  Very verbose.

Somewhere in between was
PL/1 but my point is they all do the same damn thing, but with
completely different syntax.

I programmed in the Stratus VOS variant of PL/1, but it was more like
souped up Pascal with the power of C and some weird structs.  I saw
IBM's mainframe PL/I code once, and it seemed very different and block
structured from what I saw.

I swore I'd never learn another programming language in the early
seventies, and I stuck to my word,

1970's?  Which language did you decide was your last to learn?  E.g.,

BASIC
Pascal
Fortran
Cobol
Lisp
C
Logo
Snobol
PL/I

and even now, I don't want to learn assembly language just like I
don't want to learn how to design a microprocessor.

I don't think anyone has /wanted/ to design a microprocessor since Byte
magazine of the 1980's.

Did you once learn any 8-bit assembly, e.g., 6502 or Z80?

If so, the early 8086 instructions are similar in terms of
functionality.  That's a starting point for you.  Get an early 8086
manual.

http://bitsavers.trailing-edge.com/
http://bitsavers.trailing-edge.com/components/intel/8086/

It's the layering of x86 instructions over the decades of the numerous
additional more advanced instruction sets, operating system
instructions, numerous operating modes, and mode specific instructions,
that will cause plenty of mental grief.

If you want to check out the complexity of x86, try getting lost on
this website:

https://www.sandpile.org/

I don't want to write my own assembly language programs.
I just want to watch it happen which is why I seek a tutorial.

There are some in browser emulators around.  I don't recall if any
works for x86 code.

In my not too distant past, I had, like everyone did, all the SAMS
books,

Not too distant past?  Dude, SAMS was late 1980's and early 1990's,
roughly 3 decades ago.  Did you just come out of a coma?  ;-)

--

On 20.01.2021 13:47, paul wrote:
....

I just want to learn about assembly language by running a simple tutorial.

windoze is NOT simple. In terms of easy programming it is the WORST.

I'm a low level programmer and know x86 instructions very well, but ASM tools are all different therefore I've gone the pure metal hex-way.
And once (1999) I needed to learn about windoze in general because a paying client asked for such.

similar to your problem I had no idea where to start and how to get info about available M$-functions.

I found RosAsm (for 32bit windoze) and a lot of tutorials within it.
With some help of alt.asm and clax I figured the basics of it.

So after a few weeks I could sell my very first (also my last) win-app.
Not sure if the RosAsm forum is still active. just check on it.

Nasm is merely used by Loonix coders, Fasm(Fasmw) is fine for windoze.
Masm is M$-crap (you already figured that)
Masm32 is/was? an attempt to replace Masm.
__
wolfgang

On 20.01.2021 17:01, Kerr-Mudd,John wrote:

On Wed, 20 Jan 2021 13:04:01 GMT, paul
[]

Back to the original need, I will endeavor to find a tutorial that
works on the most common computer platform in the world, using
whatever assembler that tutorial suggests.

Sorry we couldn't help; x86 is ancient technology that requires a lot of
effort to get into. I doubt there's much impetus to create a slick modern
streamlined tutorial.

The Basics weren't much to tell. Bernhard could do a few lines on it :)
I still have the twelve lessons from good old RosAsm. most lines describe just the different syntax, but beside this it explains a lot how win32 work at all. Even windoze10 is 64bit but it must support 32-bit programs as well.
__
wolfgang

On Thu, 21 Jan 2021 10:12:24 GMT, wolfgang kern
<nowhere@nospicedham.never.at> wrote:

On 20.01.2021 13:47, paul wrote:
...

I just want to learn about assembly language by running a simple
tutorial.

windoze is NOT simple. In terms of easy programming it is the WORST.

I'm a low level programmer and know x86 instructions very well, but
ASM tools are all different therefore I've gone the pure metal
hex-way. And once (1999) I needed to learn about windoze in general
because a paying client asked for such.

similar to your problem I had no idea where to start and how to get
info about available M$-functions.

I found RosAsm (for 32bit windoze) and a lot of tutorials within it.
With some help of alt.asm and clax I figured the basics of it.

So after a few weeks I could sell my very first (also my last)
win-app. Not sure if the RosAsm forum is still active. just check on
it.

Nasm is merely used by Loonix coders, Fasm(Fasmw) is fine for windoze.
Masm is M$-crap (you already figured that)
Masm32 is/was? an attempt to replace Masm.
__
wolfgang

I use nasm for DOS programs, but I've never graduated to an IDE, just an
edit, asm, debug cycle



--
Bah, and indeed, Humbug.

wolfgang kern wrote:

The Basics weren't much to tell. Bernhard could do a few lines on it :)

I doubt "paul" is interested in learning AT&T syntax. If I understood
his posts right, he tries to execute 16 bit DOS low level calls in 64
bit windoze. Never will work without an extender (DOSEMU), because 64
bit windoze denies execution of 16 bit programs - no way to get a DOS
tutorial's examples running on modern hardware.

Nevertheless, my libraries can be found here:

https://drive.google.com/file/d/0B1OgMlxNnSNEVnJNeTNSeEM1bTQ/view?usp=sharing

There is a (incomplete) HTML-Documentation for the functions and some
tutorials about basics of my programming system. (The 7z archive also
includes full source code of working programs using my libraries, all
written in 100% assembler.)


Pfüat'Di!

Greetings from Augsburg

Bernhard Schornak

On Thu, 21 Jan 2021 11:12:24 +0100, wolfgang kern
<nowhere@nospicedham.never.at> wrote:

On 20.01.2021 13:47, paul wrote:
...

I just want to learn about assembly language by running a simple tutorial.

windoze is NOT simple. In terms of easy programming it is the WORST.

Programming any GUI is complicated: working with X[*] on Unix/Linux is
not easier (and can be much harder, depending) than working with GDI
on Windows.

For command line programming, Unix/Linux and Windows use different
APIs, but the complexity of just using OS calls is roughly equivalent.

YMMV,
George

[*] typically using high(er) level Qt or GTK libraries - very few
people stoop to using the raw X API nowadays.

On Wed, 20 Jan 2021 09:41:17 +0100, "R.Wieser"
<address@nospicedham.not.available> wrote:

Paul,

I press the Windows key & the "r" key, and then I type "cmd"
and then I press the "enter" key. Whatever CLI that happens to
be called, is what I want the program I assemble to work inside of.

The problem is that you can run true (16-bit) DOS programs[1] (using INT 21h
and whatnot) as well as CLI (Command Line Interface - Windows Console)
programs (using the full gamut of Windows DLLs) in there.

[1] Caveat emptor: I'm using Win XP myself.  I have no idea if still works
under Win10.

Win10 does not natively run 16-bit software. 

There *was* an XP subsystem - separate from the "compatibility"
settings - available for Win7 Professional (or higher).  It still
works on Win10 ... but most people who could have installed it on Win7
never did, and it won't install on Win10 - the only way to have it is
via in-place upgrade of Win7 to Win10.

Best to set up a VM and run an older version of Windows (or DOS).

George

Rod Pemberton wrote:

This is a return to the 8-bit microprocessors of the 1980's. 

Yes. (IMHO)

All I'm asking for is a working noob tutorial, with an assembler, on the
most common desktop platform on the planet.

You're jumping in after decades of microprocessor development.

No. (IMHO).

The reason for the yes and for the no is...
Nothing has actually changed even when everything seems to have changed.

It's a bit more like learning calculus. 

Yes. No. (same reasons as in the above argument about the basics.
a. It's a bit more like learning quantum physics
   (e.g., if you think you understand it, you don't)
b. It's a bit more like learning evolutionary biology
   (e.g., what works isn't what's best - but what works first)
c. It's a bit more like learning modern electronics
   (e.g., it's still just an on/off switch no matter how small)

Nothing has really changed even when everything seems to have changed.

There are centuries of
knowledge which came before you got to class.  You get to start at the
very beginning.  Lucky you.

That's how _everything_ is given there has never been a freshman (biology,
chemistry, physics, calculus, etc.) class that didn't start with the basic
tenets).

Each comes with a lab (well, not calculus normally) that just works.
All I'm asking for is a tutorial that works on modern home desktops.

As an aside, why calculus doesn't come with a lab is, IMHO, because math
teachers are rather strange people who don't ever seem to comprehend that,
to make sense to most people (i.e., non mathematicians, which is most
people), the equation has to have some physical meaning.

To a freshman or sophomore calculus teacher, simply tweaking what amounts to
an almost meaningless page of similar equations, and then having the student
solve those essentially meaningless equations, is, to them, "learning".

Compare that (IMHO) idiotic approach to the other sciences, such as freshman
or sophomore physics, where no equation is taught without its commensurate
lab (whether it be Snell's law, Bernoulli's equations, Young's double slit
experiment, etc., where, without a lab, there is no real understanding
involved.

All I'm asking for... is the lab.
Labs always work.
In a well-designed lab, the learning is in watching it work.

1970's?  Which language did you decide was your last to learn?  E.g.,

(a) BASIC <== I wrote plenty in the early days of "home computers"
(b) Pascal <== never touched the stuff
(c) Fortran <== of course - every engineer learned Fortran
(d) Cobol <== why I took COBOL then still astounds me today
(e) Lisp <== no but many interpreted software interfaces are similar
(f) C <== no but we used to have to run Makefiles more often then than now
(g) Logo <== never even heard of it
(h) Snobol <== no, thank God
(i) PL/I <== yes, of course - but we called it PL/1 (Pea El One)
(j) Assembly Language <== everyone learned the IBM Assembly language
(k) Shell scripting <== didn't we all learn c-shell & tsh

and even now, I don't want to learn assembly language just like I
don't want to learn how to design a microprocessor.

I don't think anyone has /wanted/ to design a microprocessor since Byte
magazine of the 1980's.

I used to love Forest Mims' simplicity of TTL code where everybody had the
yellow Texas Instruments books next to the blue National Semiconductor books
for digital and analog chips of the early days of ICs.

If you were really into linear ICs, you dug into the off-yellow Burr Brown
datasheets, but most of us were content with the TI TTL series well before
CMOS became the norm.

We all made the same circuits, e.g., who didn't build their first LED design
with a 555 timer in those days? And who didn't burn out a few Germanium
"tophat" transistors using a 9-volt battery breadboarding their first one
and two transistor amplifier?

In those days, we followed the tutorial.
Nothing has changed over time even as everything seems to have changed.

Did you once learn any 8-bit assembly, e.g., 6502 or Z80?

With the Forest Mims pamphlets from Radio Shack or the SAMS guides, of
course, like everyone, I played with the Commodore 64, Z80, Motorola 6800
series CPUs.

Mostly I learned using the Motorola 68701, simply because I had the SAMS
Guides. I wire wrapped and breadboarded the designs like everyone else did.

Which is my point of having a tutorial that works.

If so, the early 8086 instructions are similar in terms of
functionality.  That's a starting point for you.  Get an early 8086
manual.

I have Peter Norton's book in my hands:
Peter Norton's Assembly Language Book for the IBM PC (Norton & Socha)
(c) 1989 by Brady Books

But it doesn't come with an assembler.

http://bitsavers.trailing-edge.com/
http://bitsavers.trailing-edge.com/components/intel/8086/

Nice stuff!
But no tutorials with assemblers were there.

121748-001_8086_Relocatable_Object_Module_Formats_1981.pdf
210200-002_iAPX88_Book_1983.pdf
210200_iAPX88_Book_1981.pdf
210912-001_iAPX_86_88_186_188_Users_Manual_1985.pdf
210954-002_iAPX_86,_88,_186_Microprocessors_Part_II_Jul_84_NJ7P-S.pdf
210976-002_iAPX_86,_88,_186_Microprocessors_Part_I_Ver_2.0_Jun_84_NJ7P-S.pdf
9800697B_SDK-86_Assembly_Manual_Nov78.pdf
9800698A_SDK-86_Users_Man_Apr79.pdf
9800699-03C_SDK-86_Monitor_Listings_Sep80.pdf
9800722-03_The_8086_Family_Users_Manual_Oct79.pdf
9800749-1_MCS-86_Assembly_Language_Reference_Guide_Oct78.pdf

It's the layering of x86 instructions over the decades of the numerous
additional more advanced instruction sets, operating system
instructions, numerous operating modes, and mode specific instructions,
that will cause plenty of mental grief.

Nothing has changed even as everything seems to have changed.
All I need is what any noob would need, which is a simple lab.
That lab would start with an assembler & small programs that work.
Those small programs would start with "hello world" perhaps.
Or maybe adding two numbers.
Or maybe even division. And jumps. And pushing & popping on & off stacks.
Whatever.

But they'd all work.
The learning in a lab is from watching it work.

That's why labs exist and that's why tutorials exist (same thing).

If you want to check out the complexity of x86, try getting lost on
this website:
https://www.sandpile.org/

Complexity is for math teachers.
IMHO, math teachers are the only science teachers who don't know how to
teach.

No physics teacher would think of teaching physics without a lab.
No physics teacher would throw a bunch of meaningless equations on a test.
No physics teacher would present an equation without a real-life example.
etc.

Math teachers pull that crap all the time because, IMHO, math teachers don't
know how to teach (in general). Math is a lab science, just as much as
assembly language programming is a lab science.

Without the lab (aka tutorial), learning assembly language programming for a
noob, is, imho, worthless.

The learning is by watching it work.
Not by designing complex code from the start.

I don't want to write my own assembly language programs.
I just want to watch it happen which is why I seek a tutorial.

There are some in browser emulators around.  I don't recall if any
works for x86 code.

I just want a tutorial for noobs that comes with an assembler that works.
 

In my not too distant past, I had, like everyone did, all the SAMS
books,

Not too distant past?  Dude, SAMS was late 1980's and early 1990's,
roughly 3 decades ago.  Did you just come out of a coma?  ;-)

Nothing has changed even as it may seem everything has changed.

Why do you think they teach Newtonian Physics, almost universally?
Why do you think they don't START kids on Quantum Mechanics instead?

Think about that.
Almost everything in Newtonian Physics is dead wrong, right?

Almost everything in Newtonian Physics is contradicted in Quantum Physics.
And yet, they teach the noobs Newtonian Physics first, right?

Why?
Because of two things that I seek in this quest for a working tutorial:

(1) Nothing has changed even if it seems everything has changed, and,
(2) Noobs learn best by observing things working first.

All I want is a working noob tutorial with a working freeware assembler
(on the most common home desktop computing platform on the planet).
--
DISCLAIMER: This has been my most humblest of opinions throughout.

paul <nospam@nospicedham.nospam.invalid> writes:

All I'm asking for is a working noob tutorial, with an assembler, on the
most common desktop platform on the planet.

Hi paul,

   Have you looked at the MASM32 forum?

http://www.masm32.com/board/index.php?

One of the subforums is

               Mikl__'s ml64 examples

which has a 64-bit Windows tutorial/


   And the The MASM32 SDK is available at

http://masm32.com/

which has a old version of MASM to install and
has 32-bit Windows examples.  A full install gives
you quite a lot of MASM code examples.

Regards,

Steve N.

On Sat, 23 Jan 2021 07:24:16 GMT, paul
<nospam@nospicedham.nospam.invalid> wrote:

Rod Pemberton wrote:

This is a return to the 8-bit microprocessors of the 1980's. 

Yes. (IMHO)

All I'm asking for is a working noob tutorial, with an assembler, on
the most common desktop platform on the planet.

[]

All I want is a working noob tutorial with a working freeware
assembler (on the most common home desktop computing platform on the
planet).

I don't think you can have it; all existing asm tutorials are historic
and will, generally, use DOS on an IBM PC in real mode. No 64 bit
(probably not 32bit), no Windows (especially 7/10).

If you truly want to do this (rather than repeatedly ask for the
unavailable) then you'll have to install a DOS emulator, install the
tutorial of choice, learn x86 asm, move up to 32 bit then do some windows
calls, look at 64 bit, and *then* you can put together asm code for
Windows 10.

I think this has been said before, so I'll stop now.

--
Bah, and indeed, Humbug.

On Sat, 23 Jan 2021 08:24:16 +0100
paul <nospam@nospicedham.nospam.invalid> wrote:

Rod Pemberton wrote:

This is a return to the 8-bit microprocessors of the 1980's. 

Yes. (IMHO)

All I'm asking for is a working noob tutorial, with an assembler, on
the most common desktop platform on the planet.

Unfortunately, it almost appears that assembly, not just for x86,
almost isn't being taught anymore.

After a bunch of different Google searches, I'm not sure if there is
anything that will meet all your requirements in a single complete lab
tutorial.  There is plenty of stuff online though.

Youtube (videos)
https://www.youtube.com/results?search_query=x86+assembly

Google (pdf)
https://www.google.com/search?&q=x86+assembly+pdf
https://www.google.com/search?&q=university+x86+assembly+pdf

NASM tutorial (text)
https://www.tutorialspoint.com/assembly_programming/index.htm

x86 tutorials, calling the host OS (text/image)
https://cs.lmu.edu/~ray/notes/x86assembly/

Hackr.io's assembly tutorials (free & paid)
https://hackr.io/tutorials/learn-assembly-language

Udemy's Assembly language courses (paid)
https://www.udemy.com/topic/assembly-language/

MIT OpenCourseWare "Intro to Assembly Language" (video)
https://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-004-computation-structures-spring-2017/c10/c10s2/intro-to-assembly-language-8-13-/

x86-64 Assembly Language Programming with Ubuntu (pdf)
http://www.egr.unlv.edu/~ed/x86.html

There are lots of other course websites, some 50+ besides Udemy, like
Coursera & edX, including another dozen or so that specialize in
programming courses. That doesn't include free Computer Science courses
online at major universities. For the most part, I don't see any
assembly courses. These sites seem to focus on high-level programming
languages used by Silicon Valley software tech companies, and
certifications.

--

On Sat, 23 Jan 2021 08:24:16 +0100, paul
<nospam@nospicedham.nospam.invalid> wrote:

Rod Pemberton wrote:

This is a return to the 8-bit microprocessors of the 1980's. 

Yes. (IMHO)

All I'm asking for is a working noob tutorial, with an assembler, on the
most common desktop platform on the planet.

You're jumping in after decades of microprocessor development.

No. (IMHO).

The reason for the yes and for the no is...
Nothing has actually changed even when everything seems to have changed.

The problem is that a noob can't sensibly write anything in assembler
for a modern 64-bit chip.  Whether or not you care to admit it, LOTS
of things have changed since the old days.  You say you learned IBM
assembler (700? 360?) ... if you remember any of it that is a good
start, but a modern x86 has a vastly larger instruction set.
https://stefanheule.com/blog/how-many-x86-64-instructions-are-there-anyway/

You really do need to start with something simpler and work up.  There
are plenty of good guides for 8086 assembler.  Set up a virtual
machine running DOS or an old version of Windows[*] and learn on that.
Once you get reasonably good at 8086, then tackle 80386.


[*] XP or earlier (at least 32-bit versions) will run 16-bit code, and
much of what you learn about using the Windows API will carry forward.
Argument widths have changed and new functions have been introduced,
but nearly all of the functions that were available in Windows 3 circa
1990 are still in Windows 10 today.

Nothing has really changed even when everything seems to have changed.

Wrong. The biggest change is that modern operating systems require
programs be run in protected mode. Moreover, as x86 moved from 16 to
32 to 64 bit, certain architecture changes have forced newer programs
to be structured differently.

All I'm asking for... is the lab.
Labs always work.
In a well-designed lab, the learning is in watching it work.

What school did you go to?  Labs always have been about screwing up
and discovering why you DIDN'T get the right result.  If you were
lucky you got to repeat the labs until you finally did them correctly.

1970's?  Which language did you decide was your last to learn?  E.g.,

(a) BASIC <== I wrote plenty in the early days of "home computers"
(b) Pascal <== never touched the stuff
(c) Fortran <== of course - every engineer learned Fortran
(d) Cobol <== why I took COBOL then still astounds me today
(e) Lisp <== no but many interpreted software interfaces are similar
(f) C <== no but we used to have to run Makefiles more often then than now
(g) Logo <== never even heard of it
(h) Snobol <== no, thank God
(i) PL/I <== yes, of course - but we called it PL/1 (Pea El One)
(j) Assembly Language <== everyone learned the IBM Assembly language
(k) Shell scripting <== didn't we all learn c-shell & tsh

So, except for the one assembler, you only learned relatively high
level languages.  Some C would have been helpful.

I used to love Forest Mims' simplicity of TTL code where everybody had the
yellow Texas Instruments books next to the blue National Semiconductor books
for digital and analog chips of the early days of ICs.

Then your head will explode when you look at x86-64 and the prospect
of interfacing with any modern operating system.


George

George Neuner <gneuner2@nospicedham.comcast.net> writes:

The problem is that a noob can't sensibly write anything in assembler
for a modern 64-bit chip.

I teach about 70 noobs every year to write something in assembler for
a modern 64-bit chip, so I obviously disagree.

Whether or not you care to admit it, LOTS
of things have changed since the old days.  You say you learned IBM
assembler (700? 360?) ... if you remember any of it that is a good
start, but a modern x86 has a vastly larger instruction set.

So what?  You don't need to know every instruction to sensibly write
something in assembler.  And I expect that nearly all of these
instructions also work in 16-bit mode; conversely, if you want to
pretend that the 64-bit CPU you use is only an 8086, you can just as
well pretend that this CPU has no 80387, no MMX, no SSE, no AVX and
later extensions, and you end up with a similar number of instructions
as the 8086, and probably fewer that you really want to use (on the
8086 you wanted to use instructions like XLAT and LODS, you normally
don't on a modern CPU).

You really do need to start with something simpler and work up.  There
are plenty of good guides for 8086 assembler.  Set up a virtual
machine running DOS or an old version of Windows[*] and learn on that.
Once you get reasonably good at 8086, then tackle 80386.

I don't think that's a good approach.  If you can write a program for
a task for the 8086, it's easier and better to write it for IA-32 or
AMD64 (the 32-bit and 64-bit descendant architectures; the 8086 is
quite different from them, while they are relatively similar to each
other), and you don't need more different instructions for it, rather
on the contrary, see above.

There may be fewer good guides; but using a search engine ("assembler
guide"), I find on the first page two IA-32 guides, one AMD64 guide,
some for other architectures, none for 8086.  When looking for AMD64
guides, note that this architecture is also known as x86-64, x86_64,
x64, and Intel 64.

- anton
--
M. Anton Ertl                    Some things have to be seen to be believed
anton@mips.complang.tuwien.ac.at Most things have to be believed to be seen
http://www.complang.tuwien.ac.at/anton/home.html

George Neuner wrote:

The problem is that a noob can't sensibly write anything in assembler
for a modern 64-bit chip.

The goal is & was a simple noob assembly language tutorial for a modern home
computer, where an example comparison is any decent Android Studio tutorial.
https://google-developer-training.github.io/android-developer-fundamentals-course-practicals/en/Unit%201/11_p_hello_world.html
https://www.journaldev.com/8988/android-studio-tutorial-hello-world-app
https://www.tutorialspoint.com/android/android_hello_world_example.htm
https://www.androidauthority.com/hello-world-android-studio-development-877538/
https://crunchify.com/build-hello-world-android-app-with-android-studio/

Whether or not you care to admit it, LOTS
of things have changed since the old days. 

The only thing that "may" have changed is that a set of noob tutorials for
X64 Windows perhaps doesn't exist.

Other than that, nothing has changed as a push, pop, mov, and, xor, nor,
ret, int, call, jnz, dec, jne, cmp, je, etc., are the same then as now.

You say you learned IBM assembler (700? 360?) ...

As I recall, it was Fortran on the IBM 1130 and assembly language on the IBM
360/370, now that you jiggle my core memory. I remember a "Winchester" drive
was a big deal in those days.

if you remember any of it that is a good
start, but a modern x86 has a vastly larger instruction set.

I remember burning the EPROM for the Motorola 68701 board, where I "wrote"
in hex, given it was easier than remembering the handful of "higher level"
assembly language commands. The only thing that bothered me when I started
with 8086 was the memory addresses being reversed. But that was decades ago
when my core memory held residual magnetism.

I just wanted to run an assembly language "lab", in an hour or two at home
on my home desktop computer, that's all. It seems that this isn't going to
happen unless I can find a suitable working tutorial.

As I said many times, a chemistry lab is designed to work. The student
checks out the beakers, thermometers, Bunsen burner, and chemicals, and then
the student follows the "hello world" and other beginner labs, and learns by
watching what happens.

That's what tutorials do.
(1) The tutorial is designed to work
(2) The student simply follows the instructions
(3) That's how the student learns

If learning that way wasn't one of the best ways to learn, then labs
wouldn't exist. Yet labs exist in all hard science classes except math
classes (because math teachers, imho, don't know how to teach).

https://stefanheule.com/blog/how-many-x86-64-instructions-are-there-anyway/
You really do need to start with something simpler and work up.

That's what a "hello world" is. :)

There are plenty of good guides for 8086 assembler.  Set up a virtual
machine running DOS or an old version of Windows[*] and learn on that.
Once you get reasonably good at 8086, then tackle 80386.

I can set up a virtual machine in Windows 10, I guess. The point is that the
tutorial should tell me exactly what to do given I'm on the most common home
computing platform on the planet.

A well written tutorial would
(1) Tell me how to set up the VM (I'd use VirtualBox most likely)
    in my host OS (Windows 10 x64)
(2) Tell me where and how to get the DOS guest OS and what switches
    to set it up as so that it works inside a current VirtualBox VM.
(3) Tell me where and how to get a working assembler and then run
    me through a half dozen or more basic noob assembly language labs.

[*] XP or earlier (at least 32-bit versions) will run 16-bit code, and
much of what you learn about using the Windows API will carry forward.
Argument widths have changed and new functions have been introduced,
but nearly all of the functions that were available in Windows 3 circa
1990 are still in Windows 10 today.

Exactly.
Nothing has changed even as it seems to some that everything has changed.

Nothing has really changed even when everything seems to have changed.

Wrong. The biggest change is that modern operating systems require
programs be run in protected mode. Moreover, as x86 moved from 16 to
32 to 64 bit, certain architecture changes have forced newer programs
to be structured differently.

A simple "hello world" should still work, as should adding of two numbers,
and comparing two registers, etc.

Do you work on cars? I do. Nothing has changed even as it seems to some that
everything has changed. Sure, we didn't have cats nor radial tires way back
then, and we no longer need to file our points or replace the condenser, nor
do we twist the distributor to set the timing, but the basics are still the
same, whether a carb or a fuel injector atomizes the fuel air mixture to a
stoichiometric ratio in the intake manifold.

The repair basics are the same whether or not the radiator is plastic or all
metal as it was in our early days. The exhaust system has a few more parts
but it's basically the same thing, as is the air conditioning system even as
the refrigerant has changed composition.

Likewise, the friction materials changed composition, but the brakes have
only gotten easier to work on over the years, as has alignment.

To some, everything has changed but in reality, nothing has changed.
(1) An alternator then is as an alternator is now.
(2) A spark plug then is as a spark plug is now
(3) A "fan belt" then, is as a fan belt is now (however serpentine).

Sure there are a few more components (e.g., oxygen sensors and secondary air
systems), but what worked then is as what works now.

Anyone who claims otherwise either knows a lot more than I do about cars, or
knows a lot less than I do (as I argue it's almost the same now as then).

Same with binary bits, hex code, and the "higher level" assembly language.

What school did you go to?  Labs always have been about screwing up
and discovering why you DIDN'T get the right result.  If you were
lucky you got to repeat the labs until you finally did them correctly.

Huh? They hand you two aspirins or two caffeine tablets and you extract the
acetyl salicylic acid or caffeine and they grade you on your resultant mass.
You learn by doing.

They give you a chunk of wood and they grade you on the volume of methyl
alcohol you distil after heating under a Bunsen burner & cooling with water.

You roll polished steel marbles down chutes shaped as catenaries, parabolas,
angled ramps, & brachistrochrones, and you get graded on your accuracy in
writing down the stopwatch times.

Didn't you ever do ANY of that?

You never sliced cones of clay with handheld wire to form parabolas,
hyperbolas, and ellipses?

You never positioned variously shaped antennas (the control being isotropic)
varying distances from radio transmitters to calculate received signal
strength? That's how you learn what a base-10 decibel is, mind you.

In fact, Galileo did the same thing, in effect, by timing the volume of
water filling a glass when rolling objects of varying mass down an incline.
That's how you learn non Euclidean geometric math, mind you.

Just cutting out with tweezers a teeny tiny chunk of sodium metal previously
in kerosene, and then dropping a pinhead-sized morsel of sodium into a pan
of water, just once, will teach you a lot about redox potentials mind you.

Hell, just pulling the trigger on something as simple as an oxygen dispenser
focused onto a previously heated red-hot chunk of steel teaches you a ton
about oxidation.

Most humans are not math teachers.
Most humans learn by watching what really happens in the real world (imho).

Only math teachers haven't figured that learning method out yet.
 

So, except for the one assembler, you only learned relatively high
level languages.  Some C would have been helpful.

I kind of like low level languages with the less syntax, the better.
After COBOL, I became allergic to higher level language syntax errors.
They all do the same damn thing but each enforces different syntax rules.

I used to love Forest Mims' simplicity of TTL code where everybody had the
yellow Texas Instruments books next to the blue National Semiconductor books
for digital and analog chips of the early days of ICs.

Then your head will explode when you look at x86-64 and the prospect
of interfacing with any modern operating system.

Nope. (IMHO anyway)

Just like the fact that cars haven't fundamentally changed in 100 years, and
chemistry hasn't changed in the past 1,000 years, and humans haven't changed
in the past 10,000 years, and the weather hasn't fundamentally changed in
the past 10,000 years, computers haven't fundamentally changed in the least.

Click here to read the complete article

Anton Ertl wrote:

I teach about 70 noobs every year to write something in assembler for
a modern 64-bit chip, so I obviously disagree.

At some point, rather soon, I'm going to have to give up on asking and just
start following _somebody's_ tutorial on my X64 Windows 10 desktop.

Given that, what do you think of this "Understanding Windows x64 Assembly?
https://sonictk.github.io/asm_tutorial/

And, what do you think of these Windows x64 assembly language guides?
https://sonictk.github.io/asm_tutorial/#additionalresources

There may be fewer good guides; but using a search engine ("assembler
guide"), I find on the first page two IA-32 guides, one AMD64 guide,
some for other architectures, none for 8086.

If nobody proposes anything better, I'm gonna just start with that stuff.
Even so, the guy (sonictk) says his web page is not a tutorial for noobs.
 
Yet the guy (sonictk) claims the starting environment only needs to have:
(1) A Windows 10 PC (x64)
(2) He claims we need Emacs https://github.com/sonictk/lightweight-emacs
    But, due to muscle memory, I'd vastly prefer editing in GVim (aka "vi")
    https://www.vim.org//download.php/#pc
(3) He used "Visual Studio 2017" for his C/C++ development environment
    where I've learned over the years it's almost always best to use the
    EXACT sub version of tools the tutorial author used himself.
(4) He used the "Netwide Assembler" compiler version 2.13.03
    https://www.nasm.us/pub/nasm/releasebuilds/2.13.03/

I think it's crazy to need "Visual Studio" just to assemble on a Windows x64
PC, but if nothing better comes up, that's what I'll start with, as it seems
I am forced to write my own noob tutorial from scratch (simply because,
shockingly so, a decent x64 tutorial for noobs hasn't yet been proposed (or,
if it has, I must have missed it).

Anyway, I'll write my own tutorial - but it's crazy that I have to do that.
All I'm asking in this post is if the sonictk site seems reasonable to you.

paul <nospam@nospicedham.nospam.invalid> writes:

Given that, what do you think of this "Understanding Windows x64 Assembly?
https://sonictk.github.io/asm_tutorial/

It discusses more stuff than I do (in particular, I focus on
architecture when teaching assembly and discuss microarchitectural
stuff like caches and TLBs only in my "efficient programs" course),
but otherwise seems ok.  Whether it works as a tutorial, is probably
up to you to determine; I have no checklist for assembly tutorials.

And, what do you think of these Windows x64 assembly language guides?
https://sonictk.github.io/asm_tutorial/#additionalresources

Maybe it would be a good idea to start with the introduction by Chris
Lomont and only then continue with the guide by sonictk.

Yet the guy (sonictk) claims the starting environment only needs to have:
(1) A Windows 10 PC (x64)
(2) He claims we need Emacs https://github.com/sonictk/lightweight-emacs
   But, due to muscle memory, I'd vastly prefer editing in GVim (aka "vi")
   https://www.vim.org//download.php/#pc

I see only one mention of Emacs on the page, but only as an example of
"a C/C++ development environment".  So I think you can just as well
use vi.

I think it's crazy to need "Visual Studio" just to assemble on a Windows x64
PC

Looks crazy to me, too, but then, I don't program on Windows; I guess
Visual studio is used for what I would do with xterm (have a window
for command-line interaction), bash (the command-line interpreter),
and make (a build tool).

- anton
--
M. Anton Ertl                    Some things have to be seen to be believed
anton@mips.complang.tuwien.ac.at Most things have to be believed to be seen
http://www.complang.tuwien.ac.at/anton/home.html