[Info-vax] How to write "Hello, world" in x86 assembly (llvm-mc)?
Jake Hamby (Solid State Jake)
jake.hamby at gmail.com
Tue Nov 7 20:25:01 EST 2023
On Tuesday, November 7, 2023 at 3:46:05 PM UTC-8, Chris Townley wrote:
> > Simon's right about the code I posted declaring the 64-bit descriptor incorrectly. The "must be -1" field must be a .long and not a .word. After fixing that issue and adding the line above, it all works now.
> So now Goodbye world?
> :)
You know, I learned something today. A few things, actually. :)
By design, VMS's close adherence to the AMD64 ABI is going to make porting programs that generate JIT code much easier than it could've been. The nightmare I dealt with a few years ago, as part of yet another hobby distraction, was 64-bit PowerPC Linux. It's the only ELF architecture I know of where the version 1 was so relatively bad that the stakeholders all collectively went with a cleaner ELFv2 ABI with e.g. direct function pointers instead of function descriptors and a few other changes to make it less like AIX and more like the 32-bit PowerPC ABI.
At the same time, IBM and the Linux distros switched over to little-endian, for ease of porting, so now there's a "ppc64le" that uses ELFv2 and the original "ppc64" which can use either ELFv1 or ELFv2. But you can't keep them both on the same system at the same time because the shared libraries have to be one or the other.
This is how I know how painful it can be if an OS ABI diverges from the norm, whatever it is. All the ppc64 specific code had to be modified to look at big-endian vs. little-endian and also which version of the 64-bit ELF ABI you're compiling for. The shared libraries can't interoperate either, so your Linux install has to be one or the other. Statically-compiled executables can run on any kernel, but very few programs are statically linked. So it pays to get things right the first time.
Some other things I learned: VMS Pascal is probably the nicest supported language if you want to be able to access native VMS APIs with the least hassle, have the fewest dependencies on an RTL ("Hello world!" using VMS calls doesn't even need PAS$RTL.EXE, and still be able to do all the unsafe pointer arithmetic we all know and love from C. I wonder how tricky it would be to try to mechanically convert Ada 83 programs into VSI Pascal. It'd be the cleanest fit, not generated C code.
Conversely, MACRO-32 code is especially ugly on x86-64 because it has so few registers and therefore by necessity there's a thread-local pointer to an Alpha register block that's used to pass parameters around for MACRO code that assumes an argument pointer and VAX stack layout. I learned that the hard way, figuring out why "The Halls of ZK" wasn't working. I wouldn't be surprised if there aren't a number of hot code paths in the VMS executive that were never an issue for Alpha or Itanium that are now in need of being rewritten because they're passing too many values in fake Alpha registers instead of natively.
More information about the Info-vax
mailing list