Macro-32/64

[IlyaNXX]

Is it possible to make Macro assembler a special multi-platform low-level language compiler, a replacement of C?

It seems that a program written is this language may produce more efficient code than one written in C, even if the processor's architecture differs from that of VAX.

[Volker Halle]

IlyaNXX,

welcome to the OpenVMS ITRC forum.

The VAX MACRO-32 assembler language is useable with the MACRO-32 compiler ($ MACRO/MIGRATE) on both OpenVMS Alpha and OpenVMS I64.

If you only write programs to be run on OpenVMS, you can certainly write highly portable and efficient code in MACRO-32. Part of the OpenVMS operating system is written in this language.

Volker.

[Robert Gezelter]

IlyaNXX,

I concur with Volker: MACRO-32, the original assembly language for the VAX-11 architecture, is indeed a compiler on Alpha and Itanium.

For the past several years, compilers produce code that is on the whole, far more efficient than that produced by hand. It is possible to produce very efficient code segments by hand in assembler, but the number of cases (and the sizes of those cases) has been on a downtrend for many years (literally decades).

Often the most cost effective strategy is not to write the code in assembler; but to use the machine language listing feature to display the generated machine language code and change the source code (and declaritives) so that the compiler is better able to generate efficient code.

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

[IlyaNXX]

Macro assembler allows a programmer to define directives that may replace a sequence of pre-defined assembler commands. This in my view leads to a language of near-high level programming.

This ultimately may lead us to a completely new high-level programming language with high understandability and as such more efficient code.

For example, a .PRINT directive may be defined as a sequence of commands that call OS' functions to print a string. Just the same, .MSGBOX may also call system interrupt to display message box.

For example when programming for Macro-11 I defined .LINE derictive to draw a line (is was simply a more programmer-friendly call for EMT interrupt).

So why not to port Macro-32/Macro-64 to x86-64 architecture as an universal low-level assembler-like language (without porting OpenVMS)?

[Jon Pinkley · Accepted solution]

>>>Is it possible to make Macro assembler a special multi-platform low-level language compiler, a replacement of C?<<<

It is possible, and it has been done for the Alpha and Itanium architectures. For other architectures; what is the business case, and who will pay for the work?

There are existing versions of MACRO32 for the two processors that replaced the VAX, because there was a business case for doing so. The Alpha assembler MACRO64 was not ported to the Itanium.

Why would MACRO32 be considered preferable to C? There have been other "system implementation languages" written as replacements for macro assemblers, two examples I have used are HP's SPL (a Pascal like language that was written for the HP-3000, used to write parts of MPE) and the DEC sponsored BLISS language.

BLISS has a more powerful macro facility than C and as least as powerful as MACRO32. However, BLISS licenses had a steep price until it was released to freeware status, and it never gained much of a following. BLISS really isn't a general-purpose language (no built in floating point support for example).

I have heard that BLISS was an acronym for "Bill's (Wulf) Language (for) Implementing System Software", but that may have been something that was retrofitted once the name had been set.

>>>It seems that a program written is this language may produce more efficient code than one written in C, even if the processor's architecture differs from that of VAX.<<<

John R. will have the definitive answer to your question, but my guess is current C compilers generate more efficient code than the MACRO32 compiler. The MACRO32 compiler is inhibited by the fact that it has to emulate what the VAX hardware did, i.e. it has to consider side effects of VAX instructions, e.g. condition codes and register pairs. The reason MACRO32 was ported to the Alpha and Itanium is NOT because it generated more processor efficient code; it is used because it was easier to port the assembler to a compiler than to port all the existing MACRO32 code in the OS, with the side benefit that customer written MACRO32 code would be easier to port to the new architecture.

Code that is needs "hand optimized" isn't written in MACRO32 for the Alpha or Itanium.

If you could make a business case for porting MACRO32 to a new processor, then there would be a possibility that it would be done. I don't think you will be able to make a convincing business case, unless VMS was being ported to that processor.

But you explicitly stated in a follow-up note that what you are really asking for is a port to the x86 platform even if VMS was not ported.

Even if such a compiler existed as freeware, how many people do you think would use it? I wouldn't expect VMS users to use it if there were no VMS routines to call, and I wouldn't expect MS Windows users to write programs in it vs. using C or some other higher-level language.

What software project would you use such a compiler for?

[Paul Beaudoin]

IlyaNxx

Nothing would make me happier than to see Macro32 ported to other platforms - equally, and for the reasons others have stated, nothing would suprise me more than the anouncement that it had been done.

What you are asking sounds a lot like a project I came across years ago called 'HLA' (High Level Assembler). which started out life as an assembler teaching tool and evolved into a compiler. At the time it ran only under Windows but the authors had ambitions to make this 'more widely available' (not sure of the precise meaning of that). I have the pdf they published, though it is some years old. Probably best to google for 'HLAR' for a more recent missive. If you don't find them, it probably means the project has disappeared and my document is worth even less. If, for whatever reason, you want this copy, mail me and I'll send it.

Regards

Paul

[John Reagan]

RE: Meaning of BLISS. Officially, Bill Wulf said that BLISS didn't stand for anything. Besides the one mentioned, I've also heard Basic Language for Implementing System Software

RE: Macro-32 vs C. Both compilers use the same GEM peepholer and instruction scheduler. The C compiler uses the normal GEM optimizer and code generator and will do all sorts of good optimizations (routine inlining, loop unrolling, strength reduction, value propagation, etc.). The Macro compiler has its own flow analyzer and code generator. It is very limited at global optimizations for many reasons. That said, for certain sequences and programs, Macro-32 will generate better code. However, in general I'll go with C or BLISS.

As for condition code overhead, Macro will only materialize condition codes if it finds subsequent instructions that use them. It is a real pain to get right in the compiler (one of the reasons for our own custom flow analyzer). Consider a loop that does a compare at the bottom, a branch back to the top, and then a conditional branch. Consider again that "loops" in Macro aren't required to be properly nested.

[Hoff]

I first encountered the basic technique proposed here way back around 1980. The fellow was an absolute wizard with the Univac 1100 series Exec-8 assembler, and had his own and very gonzo macro libraries. Yes, it looked like higher-level code. Underneath, it was still less-than-optimized Exec-8 assembler.

The VAX CISC instruction set of Macro32 was a good design. In 1978.

The macro pre-processor within Macro32 itself is a pretty good tool. Certainly on par with the (then-)Univac assembler.

If you're looking at macro capabilities -- and the macro capabilities of C, for instance, are comparatively weak -- I'd suggest you look also at code generation and code optimization, and at tasks such as code maintenance. The C pre-processor is comparatively bad. The code generators in most of the compilers, on the other hand, are usually pretty good.

Do also look at the difficulties in coding and debugging and maintaining the target macro-fied (or in-lined) language. I've seen various language that started out as pre-processor language built on another compiler or as cross-compilers, and these then evolved into compilers. (Debugging macros is "fun"...)

Also look at whether or not the underlying platform is portable. VAX Macro32 really isn't immediately portable, as you'd need to build an assembler with analogous macro capabilities, and then graft it onto a code generator if/when you moved beyond the OpenVMS platforms.

Creating a new language is the comparatively easy of the aggregate effort here. Getting an installed base isn't quite so easy.

As for the installed base, starting out with a language design from thirty years ago won't get the attention of the kids. I'm one of many folks that have debugged Macro32 macros on many occasions, and it gets ugly -- Macro32 isn't all that much better than the Exec-8 stuff. And ugly and dense code that's difficult to debug isn't going to be a good bullet to include in the language presentation-ware.

As for inlining, various current compilers can inline what appear to be called functions. That is, the compilers are generating and substituting the called code directly into the instruction sequence, rather than calling a subroutine. This in-lining can arise with user code, and with specific and frequently-used system functions. The trade-off is image size for execution speed -- but the compiler has also optimized the code, and is here optimizing to eliminate function calls where that can contribute to aggregate speed.

Tegardless of any inferences you might draw from the above, if you really believe in this approach, go prototype it. Build it. Document it. That's what Tim Burks did with his Nu language, for instance. For a code generator, go look up LLVM. And I certainly look forward to taking your new language out for a spin...

[Dean McGorrill]

my .02, the nsp transport in decnet was written in macro. It was tedious to work on
to say the least. as to compilers, I wouldn't mind bliss leaking into the mainstream!

[Jon Pinkley]

A usenet discussion from 15 years ago:

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

http://groups.google.com/group/vmsnet.internals/browse_thread/thread/bfc8bbc35bddf19a/8477da517c678f33?#8477da517c678f33

It even has some references to MACRO32.

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