Nice lecture info on Intel internals for newbies

[K_F]

On other hand, I wish MASM had an undefine directive

'ASSUME' .. nothing/something else ?

[sinsi]

You can undefine a macro with PURGE, if that's what you mean (since there is no define in masm)

[rrr314159]

@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

[hutch--]

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.

[Gunther]

Hi rrr,

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

[rrr314159]

Why should a HLL need another kind of HLL (sophisticated macro engine) inside?

I admit a good HLL shouldn't have to use them {macros}

You can not compare apples and pears.

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.

[Gunther]

Hi rrr,

right, you wrote that, but the following, too:

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

[rrr314159]

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 ...

[Gunther]

Hi rrr,

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