Early this summer I started work on what I thought would be a modest change: convert SPITBOL from using the GNU GAS assembler to my favorite X86 assembler, NASM. I also wanted to do some code cleanup as part of this.
Alas! What I thought would take a few weeks took a few months.
I make no excuses. The fault was mine, and I knew it was my job to fix it.
I also soon realized that while it would take longer, the work was needed, as I hadn’t worked on SPITBOL in almost three decades, and my programming skills, especially in X86 assembler were — to say the least — quite rusty.
I had forgotten almost all — which really wasn’t that much — of SPITBOL structures and internals, so it was necessary to reacquire that knowledge — even if I had to do it the hard way.
The process was complicated by the poor support for assembly language programming provided by Linux. I knew about GDB and its visual front-end, DDD. However, I found them sorely lacking, probably because SPITBOL as I found it intermixed data and code in the code section, and this was enough to cause problems using these tools.
As a result, I implemented a variety of instruction-level traces to try to find out what was happening. That itself was an interesting experience, one that made me appreciate even more the power of SPITBOL when it comes to doing this sort of thing.
I plan to write more about this in a future post, but the immediate porting concerns must be addressed first.
The current status is as follows.
The code now available at Hardbol SPITBOL contains a directory b32
with a bootstrap compiler. This is a 32-bit word, 8-bit character SPITBOL using only TCC as the C compiler, MUSL as the library, and NASM as the assembler. The system is thus self-contained in that does not rely on gcc/gnu code.
It doesn’t support floating point.
The OSINT procedures have been cleaned up in that all mention of obsolete systems such as Windows NT, SOLARIS, and MAC (pre OSX) have been omitted.
Going forth, SPITOBL will support only one operating system — Unix.
I have started work on the port for Linux 64-bit word, 8-bit characters. I expect that won’t take too long, but given my track record, we will see…
Once I have that, I’ll try port to OSX. TCC and MUSL support OSX. If that goes well, I’ll put it out. If I run into too many problems, I’ll back off and just do the next — and key — port, for 64-bit words and 32-bit characters, as that is needed for full UNICODE support.
I’ll keep you posted.