Getting an ARM up

[samiam95124]

Getting an ARM up

So getting a desktop computer these days is really a matter of just two CPUs, which are (drumroll):

AMD64[1] - 64 bit x86 compatible CPUs.
AArch64 - 64 bit ARM compatible CPUs.

Of course ARM drives more than just desktops. The I86 and AMD64 basically lost those markets, but it wouldn't be a stretch to say that software is developed on AMD64 or AArch64 desktop machines and runs on other machines like phones and tablets.

An AMD64 machine, of reasonably recent vintage, can run Linux and Windows. That leaves Mac, and though linux and Mac, to phones and tablets. I have x86 machines covered, and have for decades. So I am interested in what is going on in the ARM world, and perhaps later, Risc-V when and if it grows up.

I have a couple of ARM small boards, and you can get a nice emulator of ARM on Linux. However, nothing beats a nice, fast ARM machine to develop on. The contenders are:

Qualcomm Snapdragon X
Apple Mac

Frankly preference would be a PC motherboard that runs ARM, but outside the server market, they frankly don't exist. They run into all kinds of compatibility and cost issues I won't get into here. So which one?

Well, they are roughly compatible in price. However, the Apple mac has something the Snapdragon does not have, which is the full Mac X operating system. On Black Friday, the price of a Mac Mini dipped below $500, so I went for it.

This is my second Mac mini, one of two computers in my house that run Mac X, and perhaps the 5th Mac computer of various I have owned. Mac computers have expiration dates. My old Mac mini was x86 based, and I watched it become slowly useless even before Apple dropped support for it. At $500, its 1/10 the price I paid for my general purpose PC, which was brand Scott, because I built it. I always build my PCs, always have.

The PC serves as a space heater, has ridiculous specs, as many monitors as I can possibly fit on a desk, and on and on. Its still far more powerful at 7 years old than any computer I have at work, and that's how I like it.

I'll be honest right now and say that I like the Mac X interface better than Linux. But then I like Windows more than Linux as well. So of course I use Linux. Why? The same reason that when I was a kid at the toy store I skipped all of the other isles in the store to the back where the Legos were. I have no interest in polished premanufactured stuff. I am not interested in what others can do. I am interested in what I can make.

Ok, Pascal-P6 on the Mac

So I previously had both Pascal-P6 and Petit-Ami running on the Mac Mini, but that was the old x86 machine. Now what happens with an ARM based machine? Petit-ami, the support library for Pascal-P6, just needs recompile and checkout for the Mac, since it is all C code. For Pascal-P6, there are two pathways into the machine:

1. A new pgen for ARM.
2. cmach.

In the second option, since cmach is pure C code with dependencies on libc, the answer is "it will run now". But there are caveats. There are always caveats.

For the first, pgen, there is about 2000 lines of code that need changing for the ARM CPU. See discussion #255 "2000 lines". Not impossible, but not trivvial.

cmach runs on the Mac (?)

Well, yes and no. Yes it will probably run out of the box after a recompile. The Mac uses clang as the C compiler, and that has different error profiles than gcc, I tried it just now, it compiles with about a page of warnings.

The next factor is that although the entire Pascal-P6 can run on cmach, it's not designed to do that at present. Doing it takes a bit of jiggering. Pascal-P6, or actually Pascal-P5, has run on the pint interpreter back before there was a pgen program. Doing it on a foreign machine like ARM is a "bootstrap". That is, cmach itsellf gets compiled, then every other program runs ontop of that. This can be done several ways, but the best way is the "packaged" mode, which was actually designed for that purpose.

The package mode is kinda cool, it takes the cmach interpreter, unites it with the intermediate code for a program and puts the whole mess into an executable program. The result is an executable program that looks identical to a fully compiled program, and the net difference is it runs slower.

This gets interesting in a bootstrap. The program that creates packaged files is a Pascaline program, so the program that creates packaged programs needs to itself to be interpreted. I put some thought into how to do this, and the best way is to compile all of the needed programs into intermediates on, say, the Linux platform, then on the target, the packaging program, genobj, is interpreted to create a packaged version of itself, then it can be used to create a packaged version of all other tooling.

The final factor is that a lot of the basic programs, pcom, pint, etc., have been getting dependencies on the service module (services.c) from Petit-Ami. The issue there is that cmach needs escapes to access that library (the same as pint and pmach).

cmach runs on Windows (?)

This is actually very similar to the Mac. pgen does not generate code for Windows at present, because the calling convention is incompatible. However, that does not apply to cmach. So the details of running on the Mac are similar to running cmach on Windows.

Epic log

The purpose of Petit-Ami and other wares is to make it easy to run on alternative operating systems as well as the main machines out there. This list has changed over the years, but still has the what I call the "basic three", which (of course) are:

1. Windows.
2. Linux.
3. Mac.

Hopefully, this note makes it clearer how we get there.

[1] Which many call x86-64. I prefer the AMD64 name because AMD designed the instruction set, just as I use I64 because Intel designed that.