Right. I am saying there is a difference between portable and non portable assembly code. If you interacted with the machine via call 05h interface, it was portable. If you accessed computer’s video memory buffer directly it wasn’t.
Good portable assembly would stub the system stuff off, anyway, and once that was done for the cpu class in focus, it was very possible to have a thin HAL and write portable code. A great deal many successful products of the era were written in pure assembly this way.
In any case, you could also get high performance multiplatform video/io assembly libraries on the market, soon enough, back in the day .. it begat a lot of Delphi units too, I seem to recall ..
> The good news is that it is very easy to write assembly which targets Apple’s computers as well as the other 64-bit ARM devices running operating systems other than Darwin.
If you can understand what someone means when they talk about a “small elephant”, then you can understand what they mean when they talk about “portable assembly”. In this case, the relevant point is that you can write ARM64 assembly routines that do useful work (e.g optimized matrix multiplication, or something like that) in such a way that they’ll work correctly on a number of different ARM64 platforms.
There are portable (or not) software applications, portable algorithms code, non-portable algorithm code.
Assembly based software for the Motorola 68000 /and/ the Amiga will not run on a 68000 Mac. A "polynomial based packed fastSin()" subroutine written using the XMM x64 registers will work on most x86 CPUs. The same written for the ZMM registers will not work on a number of x86 CPUs.
Surely 40 years ago we could easily assume talking about specific implementations of software applications; clearly today we see problems as being optimizable on some classes of platforms (e.g. the vectors in ARM work differently from the vectors in x64 CPUs).