Nice lecture info on Intel internals for newbies

[K_F]

http://www.c-jump.com/CIS77/CPU/x86/lecture.html

Edt: add the home page http://www.c-jump.com/CIS77/CIS77syllabus.htm

[dedndave]

looks like a great page for newbies   :t
should be part of any win32 tutorial

[Zen]

VAN (JAST),
Very useful intel,...THANKS !!!

[rrr314159]

Great link - really excellent writeup - but not really for newbies; not because it's difficult, but because other things are far more useful. You can be a mid-level assembly programmer and never care about how the instructions are encoded at the bit level - let the assembler handle it!

No question: for really optimizing speed and storage u have to know this stuff; and, for maximally benefitting from the debugger. But a MASM newbie would be much better off studying all the masm32 examples, and any other useful code he can get his hands on, first. Windows functions (graphics, files, database, internet, etc etc); and MACROS, which give you vastly more power than this sort of bit-level info can; and, many other topics, are more important for almost all types of assembler programming.

Maybe u define "newbie" differently than I do?

[Gunther]

But a MASM newbie would be much better off studying all the masm32 examples, and any other useful code he can get his hands on, first. Windows functions (graphics, files, database, internet, etc etc); and MACROS, which give you vastly more power than this sort of bit-level info can; and, many other topics, are more important for almost all types of assembler programming.

Are MACROS so important? I know that we've some very sophisticated macro wizzards in the forum. But though such constructs of the hll, why not use the hll? Only a question.

Gunther

[Siekmanski]

IMHO macros gives us not more power, its just a copy of the same block of code.
But it's convenient to process parameters with macros.

[rrr314159]

@Gunther,

Assume u mean HLL like C or Java, not MASM "HLL" constructs like .if, .while etc.

The answer which is perhaps a bit of a cop-out is this. We're talking about a MASM "newbie" here - so a premise of the discussion is, we're using MASM not HLL. As long as you're stuck with MASM then MACROs are very powerful and important. This is not entirely "cop-out", because I had it in mind as I wrote my comment.

But the larger q. is, if u feel the need to use MACROs so much perhaps you'd be better off using HLL which, after all, can be thought of as just a sophisticated set of built-in MACROs! That issue belongs in the larger discussion of HLL vs. MASM, which is partly opinion & taste, partly what you're used to, partly the task you're working on, and (if u have a job) totally depends on what language the company pays u to use.

My opinion is, I love assembler. But my considered answer to "which is best, MASM or HLL": if it MUST be one or the other, HLL: namely C (or C++)

@siekmanski,

Can't agree, only the simplest use of MACROs is to reproduce a block of code, gets much more interesting than that. Should give an example but, 2 lazy at the moment

[edit] having thought about it, perhaps you're right. I'm also including as part of this term MACRO all the compiler directives, like, IF .. ENDIF, SUBSTR, etc, because I tend to use them in MACROs for the most part. But of course that's not right: really MACROs are subset of directives, not the other way around

So I should have said, "Compiler directives, including MACROs" are very powerful and important. I suppose we agree on that?

[jj2007]

IMHO macros gives us not more power

Depends on how you define "power". Raw speed? No advantage, it's the same code. BUT:

Pure:

Code Select Expand

push ebx ; handle
push esi ; comline
call GetCommandLine
mov esi, eax
invoke GetStdHandle,STD_OUTPUT_HANDLE
mov ebx, eax
invoke lstrlen, esi
push eax ; slot bytes written
mov edx, esp
invoke WriteFile, ebx, esi, eax, edx, NULL
pop edx ; bytes written
pop esi
pop ebx

Masm32:

Code Select Expand

print rv(GetCommandLine)

Advanced:

Code Select Expand

Print CrLf$, "The first arg is [", CL$(1), "]"

Macros give the advanced programmer the POWER to concentrate on more difficult code.

[hutch--]

I think the real distinction is that with MASM you can write your own macros where with a HLL you have to use their format. A pre-processor is a text modification method that expands, changes or extends the typed material into assembleable code prior to assembly time and as such is a convenience that saves a lot of messy typing.

In terms of learning sequence, macros ease the entry into assembler coding, in the middle stages of learning folks learn how they work and how to write their own and at the advanced stages, the author of the macros uses their own macros or macros they well understand to speed up their final code production. With MASM you have the choice, with HLLS you don't.

[nidud]

deleted

[Gunther]

Macros used in HLL are equally sophisticated as the macros used in MASM given they are implemented as part of the design.

No doubt about that.

I agree that macros may speed up code production but I'm not so sure it will speed up the learning process.

I think it won't speed up the learning process. Macros are sometimes very individually and can be hard to read and understand.

Gunther

[rrr314159]

...and MACROS, which give you vastly more power than this sort of bit-level info can...

- The original point was that many other things, including MACROs, are more important than bit-level instruction encoding. Surely we all agree on that?

IMHO macros gives us not more power, its just a copy of the same block of code.

I should have said, "Compiler directives, including MACROs" are very powerful and important.

- Can't tell if anyone read that? You all continue to use the word "macro" as tho it includes all Compiler Directives. Admit that is common usage; that's why I used it that way; but is it correct? Dunno, but I'll continue to follow the herd, sorry siekmanski

Macros used in HLL are equally sophisticated as the macros used in MASM

No doubt about that.

- That's a new one on me. The C preprocessor in late 20th century was far weaker than MASM's macro's (including, of course, all Compiler Directives under the term "macro"!). Altho it did have a couple things I wish MASM had, it lacked many other capabilities. Has it improved that much in C++, or perhaps in C99 ? Alternatively, was my knowledge of the C preprocessor that poor? Might be useful discussion to compare them feature for feature

I agree that macros may speed up code production but I'm not so sure it will speed up the learning process.

- "may" speed up code production? Surely it will speed up production, as hutch indicates. As for learning process - it only speeds up learning about macro's. Slows down learning about assembler instructions themselves. BTW Contrary to popular opinion, equivocation is not an end in itself ;)

[jj2007]

The C preprocessor in late 20th century was far weaker than MASM's macro's (including, of course, all Compiler Directives under the term "macro"!). Altho it did have a couple things I wish MASM had, it lacked many other capabilities. Has it improved that much in C++, or perhaps in C99 ?

No, it hasn't.

As for learning process - it only speeds up learning about macro's. Slows down learning about assembler instructions themselves.

I disagree: If you have to write a thousand times the GetStdHandle and WriteFile crap, there will be no time left to study pcmpeqb.

[Gunther]

No, it hasn't.

Are you sure? Have you checked, for example, this or this?

Gunther

[rrr314159]

Gunther, read thru both those ref's, basically the C and C++ pre-processors are not the same beast as MASM macro's. Like comparing, perhaps, a crossbow to M-16. Admittedly the M-16 does have a tendency to jam, but when it works as it should, there's no contest.

jj2007, OK using macro's may leave you more time to study asm instructions! But you won't use it for that, you'll use it learn more about macro's - and to get the one you're writing to work

I admit macro's are often a PITA, I admit a good HLL shouldn't have to use them, but they're very powerful. Once you fire a burst from M-16 you'll never go back to a crossbow

One telling example of many: #define must be on one line! Sure u can use continuation character but it shows this is NOT a language, like MASM macro's. Not recursive, etc etc

On other hand, I wish MASM had an undefine directive