Re: Evolution

• Previous message: drhowarddrfinedrhoward: "Re: Evolution"
• In reply to: drhowarddrfinedrhoward: "Re: Evolution"
• Next in thread: Betov: "Re: Evolution"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Date: Mon, 17 Nov 2003 16:14:59 GMT

"drhowarddrfinedrhoward" <TAKEOUTdrhowarddrfine@sbcglobal.net> wrote in message
news:3b6ub.1022$bv5.861@newssvr24.news.prodigy.com...
> Get over it, hutch.
>
>

I suspect he will, about the same time Rene does :-)

Actually, I can relate to what Steve is doing. I went down this same
path many years ago when developing the UCR Stdlib v2.0.
It's quite possible to do amazing things with MASM's macros.
The problem, unfortunately, is that the system you wind up with
isn't very robust. It works great as long as there are no mistakes in
your code; if there is a syntax error, however, you start getting some
really bizzare and undecipherable error messages. An experienced
MASM programmer can deal with that; as this is the target for
Steve's (Hutch's) macros, that's fine. Unfortunately, I was developing
these macros for use by beginning assembly programmers and the
robustness (or lack thereof) of the result was a big problem. That,
plus the bugs I was discovering in MASM v6.11 at the time, forced
me to develop HLA rather than continue with MASM.

Note that those old macros I created are still around, interested parties
can find them at
http://webster.cs.ucr.edu/Page_asm/ucrlib/stdlibv2.html
Alas, UCR stdlib v2.0 was never finished, so the documentation on these
macros is really sparse. Also, one of the main reasons for dropping this
project is that changes between MASM v6.11a and v6.11d broke
several of my macros, so I suspect that many of these macros will not work
on current versions of MASM without some modification. Nevertheless,
they make a decent starting point for people who want to do the kinds of
things that Steve is doing. I have seen more advanced MASM macros
in the past couple of years, so the techniques in the UCR stdlib v2.0,
combined with these new techniques I've seen, might solve many of the
problems I've had in the past.

BTW, here's a cute trick for introducing "instruction composition"
into MASM:

_mov macro dest, src
          mov dest, src
          exitm <dest>
_mov endm

With this macro (and one like it for all the other instructions), you
can write code like the following:

mov eax, _mov( ebx, 0 )

which assembles into

mov ebx, 0
mov eax, ebx

Now this isn't all that useful as a stand-alone instruction (it tends
to obfuscate the code quite a bit), but it is *very* useful inside
macros.

Of course, you can even create an "HLA-like" syntax in MASM
using this trick, e.g.,

_mov macro src, dest
          mov dest, src
_mov endp

It's just too bad that MASM doesn't have the equivalent of
HLA's #ID and #RW pragmas (that let you redefine reserved
words).

Of course, the path that Hutch is headed down is a dangerous one.
The more he makes assembly look like BASIC, the more people
will complain about it (speaking from experience as one who has
made assembly look like Pascal/C :-) ).

OTOH, there are a lot of VB programmers out there, who just might
welcome the opportunity to program in an assembly language that is
a little bit closer to the language they're comfortable with. I'm all for
these types of aids for beginning assembly programmers.

Cheers,
Randy Hyde

• Previous message: drhowarddrfinedrhoward: "Re: Evolution"
• In reply to: drhowarddrfinedrhoward: "Re: Evolution"
• Next in thread: Betov: "Re: Evolution"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]