http://www.c-jump.com/CIS77/CPU/x86/lecture.html (http://www.c-jump.com/CIS77/CPU/x86/lecture.html)
Edt: add the home page http://www.c-jump.com/CIS77/CIS77syllabus.htm (http://www.c-jump.com/CIS77/CIS77syllabus.htm)
looks like a great page for newbies :t
should be part of any win32 tutorial
VAN (JAST),
Very useful intel,...THANKS !!!
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?
Quote from: rrr314159 on May 27, 2015, 04:53:01 AM
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
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.
@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?
Quote from: Siekmanski on May 27, 2015, 11:01:23 AM
IMHO macros gives us not more power
Depends on how you define "power". Raw speed? No advantage, it's the same code. BUT:
Pure:
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 ebxMasm32:
print rv(GetCommandLine)Advanced:
Print CrLf$, "The first arg is [", CL$(1), "]"Macros give the advanced programmer the POWER to concentrate on more difficult code.
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.
deleted
Quote from: nidud on May 27, 2015, 10:45:03 PM
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.
Quote from: nidud on May 27, 2015, 10:45:03 PM
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
Quote from: 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?
Quote from: siekmanskiIMHO macros gives us not more power, its just a copy of the same block of code.
Quote from: rrr314159I 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
Quote from: nidudMacros used in HLL are equally sophisticated as the macros used in MASM
Quote from: GuntherNo 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
Quote from: nidudI 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 ;)
Quote from: rrr314159 on May 28, 2015, 02:13:26 AMThe 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.
QuoteAs 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.
Quote from: jj2007 on May 28, 2015, 02:30:02 AM
No, it hasn't.
Are you sure? Have you checked, for example, this (https://gcc.gnu.org/onlinedocs/cpp/Macros.html) or this (http://www.cprogramming.com/tutorial/cpreprocessor.html)?
Gunther
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
Quote from: rrr314159 on May 28, 2015, 07:23:27 AM
On other hand, I wish MASM had an undefine directive
'ASSUME' .. nothing/something else ?
You can undefine a macro with PURGE, if that's what you mean (since there is no define in masm)
@K_F,
ASSUME edi:nothing, for instance, is similar but different, it "undefines" the assignment of a segment or structure from a register. BTW the "last straw" with ML64, reason I finally gave up on Microsoft MASM 64-bit: they dropped the ASSUME statement. Arrogant sob's hate programmers
@sinsi,
PURGE is not a real "undefine", yes it removes the def'n of a MACRO but it doesn't undefine it. So after PURGE, "IFDEF macroname" still says "yes it's defined" even tho it does nothing. In fact PURGE is equivalent to re-defining by writing a blank macro:
After:
MyMacro MACRO
--- useful statements
ENDM
,
PURGE MyMacro
is equivalent to:
MyMacro MACRO
ENDM
But what I really want an undefine statement for is STRUCT, which can't be re-defined (except identically). And it would also be very nice to undefine symbolic constants; u may remember mabdelouahab started a thread a month or two ago where we all decided essentially it can't be done (apart from a couple tricks)
p.s. I'm using the word "define" as implied by the MASM statements IFDEF, IFNDEF
Long ago (in computer terms) there was this common assumption that you taught assembler by starting with complex bit manipulation theory, abstract transformations etc .... but most of the older guys know where that ended up, the near death of low level coding in the middle 1990s. Looking back at the type of assembler learning material that was available back then, most of it had to concentrate on trivia like getting something onto the screen and paddling around doing simplistic integer maths yet the method that changed the market was very different. MASM does not come with a runtime library, something that even C89 had and this made it difficult to do even the most basic things.
By providing a basic runtime library and a matching set of macros, you could at last do simple basic things like crunch a few numbers and display the results on the screen. Having to start with designing a runtime library is a sure fire way for most people to fail as in fact was the case back in the middle 1990s. Put basic stuff like screen output, conversions, text formatting, file IO etc ... into the hands of an interested person and instead of them having to wade through a mountain of trivial junk, they can start on the real guts of assembler coding, mnemonic coding and with the help of the API can do more or less anything that higher level languages can do.
MASM is basically an industrial tool, it has never been compromised into a sloppy tolerant piece of junk like so many others, it never has held you hot little hand and will bite your hand if you get it wrong yet that is among its greatest strengths, it forces you to write code that works properly. Macros and a runtime library ease the entry into a tool of this type, by making many of the common tasks reliable and straightforward to use. The learning sequence that has delivered the most "satisfied customers" over time is the one that gives them a start without having to do it all from scratch, macros and a runtime library serve that purpose to get a person off the ground and able to make something that works.
As experience is added the person can start writing their own procedures, convert them into libraries and start writing their own macros. Once they have mastered that art they can then pick up the coding speed and production advantages by using their own runtime library and write their own macros. I have heard many theories over time of how things should be learnt but this is the one that works.
Hi rrr,
Quote from: rrr314159 on May 28, 2015, 07:23:27 AM
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.
that might be, but your argumentation is a bit strange. We're talking about a high level language, which has all the more or less fancy stuf: different forms of loops, alternatives, switch (select case) etc. And you can combine that easy. Why should a HLL need another kind of HLL (sophisticated macro engine) inside? That makes no sense. The C macro capabilites are good enough. More sophisticated tasks can be done in the hll itself.
The situation is very different from a point of view of an assembly language programmer. We have no if or else; that must be emulated via the macro engine, which should be powerful enough to handle that. That's a fundamental difference. You can not compare apples and pears.
Gunther
Quote from: GuntherWhy should a HLL need another kind of HLL (sophisticated macro engine) inside?
Quote from: rrr, same post u quotedI admit a good HLL shouldn't have to use them {macros}
Quote from: GuntherYou can not compare apples and pears.
Quote from: Gunther on May 28, 2015, 01:02:00 AM
Quote from: nidud on May 27, 2015, 10:45:03 PM
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.
- The comparison u guys made was apparently incorrect and so I corrected it.
Hi rrr,
right, you wrote that, but the following, too:
Quote from: rrr314159 on May 28, 2015, 07:23:27 AM
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
This was my point. No offense.
Gunther
That's fine, none taken I'm sure,
It occurs to me that those who are primarily C users may not be familiar with everything MASM macros can do. They can know asm very well - the part of MASM u can inline in a C prog - but not the rest. If I get unlazy I should post an overview of the capabilities for newbies - and also some oldbies who just never really looked into it ...
Hi rrr,
Quote from: rrr314159 on May 29, 2015, 04:31:11 AM
It occurs to me that those who are primarily C users may not be familiar with everything MASM macros can do. They can know asm very well - the part of MASM u can inline in a C prog - but not the rest. If I get unlazy I should post an overview of the capabilities for newbies - and also some oldbies who just never really looked into it ...
I'm not a primarly C user. I'll take only the best from both worlds. But I'm not a fan of macros, but that's only my point of view. I want nobody proselytize.
You should give that overview. It could be interesting for other coders.
Gunther