Macro-32/64

[Hoff]

... "BLISS vs. C: Which is the better language for VMS?" ...

Why oh why do I now hear "Commodore 64 versus VIC-20?" rattling around in my brain? :-)

[John Gillings]

I'd expect a MACRO32 compiler for another platform to be a relatively simple exercise, first cut would be a simple mapping of MACRO32 instructions to the underlying instructions of the target processor (though maybe John R would "correct" that impression ;-) Optimization would be a whole different ballgame.

However, even if that were done, it wouldn't exploit the big advantage in MACRO32 - easy access to all the OpenVMS system services and RTLs through STARLET macros. Unless you ported all those to the other platform, you really haven't achieved anything particularly useful. Yet another language to learn and support, and discover that the language isn't the critical component in writing truly portable "efficient" code (if there really is any such thing, or if it's a worthwhile goal in the first place!)

I still write quite a lot of code in MACRO32, but it's mostly for small, highly OpenVMS specific utiities and tools. I choose MACRO32 because I know it can be compiled on any OpenVMS system, without assuming licenses for compilers. It's also often smaller and (to my mind) more readable than the equivalent C code ;-) If I were developing anything of any size or complexity, it would definitely NOT be in MACRO32, especially if cross platform compatibility was one of the aims.

Yes, you can build macros to make more readable and structured code, but as Hoff has pointed out, debugging MACRO32 macros is all but impossible. There's no DEBUG support for displaying or stepping through the insides of a macro. Unpacking multi nested macros to discover some trivial typo can be a huge time waster.

These days "code efficiency" is not really an issue. Slicing a few nanoseconds of anything but the most frequently hit inner code paths of an OS kernel is not economically justifiable when measured against the time taken to write the code itself.

Use a well structured, high level language with good compiler diagnostics and debugging facilities.

If you're looking for a replacement for C, I'd suggest Pascal. It's a nice, friendly language which protects you from a large range of trivial errors through language rules, yet has the capability of doing very low level bit twiddling as well as high level structures through modules and schemas. Code quality from the OpenVMS compilers is excellent.

[IlyaNXX]

1. Oh no, Pascal isn't a good replacement for C for many reasons.

2. Macros should be a small pieces of highly-optimized code when porting to other platform, the programmer can change these pieces without changing all program (like definitions of constants).

3. I want to point out that if Macro-64 ported to x64 architecture, it would have a great advantage in that this architecture better resemble the original VAX one (more regicters etc).

4. Macro assembler program does not look ugly for me. It depends on programmer of course, but seems much more readable for me than C.

[Paul Beaudoin]

IlyaNxx

There is a world of difference between Macro-32 and Macro-64. I wrote lots of 32 (enough to get sorta good) but in 64 you also need to deal with the out-of-order execution possibilities of the processor (AXP) by inserting the relevant barriers. Not for anyone except the true fanatic. You can access a decent subset of Alpha instructions via 32 with the EVAX_ instructions. I have had only the briefest of glances at the Integrity assembler and it looks like another order of magnitude uglier that Alpha. M32 is still my only choice for low-level but assembler, in general, is getting less and less useful as processors become more sophisticated.

By all means continue: I like nothing more than to see the (vast) majority taught the error of their ways!

Regards

Paul

[Robert Gezelter]

IlyaNXX,

I must concur with Paul's comment. I have also worked the other end of the table (e.g., author of a code generator for a compiler for the PDP-11 architecture which ran on the IBM System/370 and VAX; and was thus involved in resolving problems with generated code on all three architectures), and have been involved as a systems programmer for many, many years tracking generated code problems on behalf of users.

It is true that handcrafted assembler is faster than poorly generated, unoptimized code. However, it has not been achievable in large volumes since the beginning of compilers, even the original IBM FORTRAN compiler in the late 1950's. The more complex the syntax or semantics of the architecture (e.g., out of order execution on Alpha, multiple simultaneous instructions on Itanium), the more difficult it is to achieve efficiency.

If one is an architect, designing a branch sequence or a call sequence (or working on the ultimate FFT or similar very dense algorithm) that will be executed billions upon billions of times per second, the days of effort on a blackboard to get things correct are justified. For most code, the cross-over will occur in the first couple of minutes.

Compiler code generators are not, by any means perfect, nor are they clairvoyant. Small changes in source language can result in major improvements in resulting code performance. The classic array index ordering change in FORTRAN (e.g., row-major vs. column-major order of processing) has a major impact. Other changes involving scoping (e.g., local variables vs. global variables) can similarly have a major impact.

While I do not recommend it when tired or fatigued, a good educational experience is to take a computationally complex code and examine an fully optimized machine language listing.

- Bob Gezelter, http://www.rlgsc.com

[John Reagan]

"port Macro-64 to x86"??? There aren't enough registers on the x86 even in full 64-bit bit mode (it only has 16). My head hurts.

As for moving Macro-32 to x86, you have a similar problem to find places for all the registers. True, old Macro-32 code would only have used the 16 VAX registers, but more recent Alpha and I64 code may have used other registers exposed by the compilers on those platforms. Moving that back to x86 is putting 10 pounds of bits into a 5 pound bag. OK, so perhaps Macro-32 could figure out which registers might be "local" (saved at entry, restored at exit) and use stack locations, but you have to deal with interrupts and unwinding and tell the system where you hid all of the stuff.