The SPITBOL Project is pleased to announce that Unix SPITBOL 13.01 is available.
It can be downloaded from Github: HARDBOL/SPITBOL:
This release supports floating-point arithmetic and save files. Load modules and the loading of external functions are still not supported.
The SPITBOL project is pleased to announce some progress in porting MACRO SPITBOL to x86-64 Linux. (I use MINT, so this should also work on straight Ubuntu.)
This version is able to compile such simple programs as “hello world” but is not yet able to compile itself.
It can be found at http://github.com/hardbol/spitbol
It has the git tag “x86-64-hello-world” and there is a file with this tag in the Downloads section.
Reaching this milestone has been a long slog, albeit an interesting project in relearning X86 assembly language and coding in SPITBOL.
The translator consists of about 3000 lines of SPITBOL code. LEX.SPT consists of about 1000 lines. It produces a file of lexemes which are fed to ASM.SPIT, which consists of about 2000 lines of code. ASM generates assembly code suitable for input to the NASM assembler.
The hard part was to configure ASM.SPT so it can generate code for X86-32 or X86-64.
To try out the system, do
$ make clean;make
$ ./spitbol test/hello.spt
To see the program in action, set Z_TRACE to 1 at the start of ASM.SPT. Then try
$ ./spitbol test/hello.spt >& ad
$ make z
This will produce a *large* file “ae” with an instruction-by-instruction trace of the MINIMAL code, showing the hardware instructions executed and a report of differential changes at the machine register level.
One of the more challenging — and fun — parts of this exercise in porting has been to produce that trace. I found available debuggers, such as GDB and its graphical front-end DDD, of little use in dealing with assembly language, and so had to write my own debugging trace tool.
I’ll keep you posted on further developments.
thanks,dave
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.
I have updated the license for MACRO SPITBOL from ‘GPL v3 or later’ to ‘GPL v2 or later’.
This was motivated by a conversation with Rob Landley, who first made me aware that that GPLv2 and GPLv3 are not compatible.
An explanation of why this is so can be found in the following post by Richard Stallman, Why Upgrade to GPL Version 3.
The result of this modest — indeed only the change from ’3′ to ’2′ in the license version — is that people wishing to use SPITBOL can now incorporate it in code licensed under any of the following combinations:
Contributions will only be accepted under the new terms — gplv2 or later — to give those who choose to use the code more freedom in their choice of license.
I just noted use of a a search phrase that resulted in reaching this blog:
бои спитболи
The second word is SPITBOL in Cyrillic (the Russian alphabet).
Ochen Xorosho (Very good).
thanks,dave
Though I try to confine myself to technical matters in this blog, I have noted that in the coverage about the attack on the American Embassy in Libya in which four Americans were slain, only the man who held the most senior position, Ambassador J. Christopher Stevens, is named.
The three others are left unnamed.
I write this note to remind all who read this that the three other Americans who were killed should not remain nameless.
As noted in CNN’s Bodies of 4 Americans killed in Libya returned to U.S. the others killed did have names:
The other men killed in Libya include Tyrone Woods and Glen Doherty, both former Navy SEAL commandos working as diplomatic security officers. The fourth was Sean Smith, an information management officer who also had an online alter-ego legendary in the gaming world.
You can learn more about them in the following articles:
Ex-SEAL killed in Libya ‘thrived on adrenaline, danger’
Sean Smith: Diplomat showed gaming generation’s online influence
A Letter to My Friend Glen Doherty
We begin life as equals.
While the trajectory of our lives varies, we are again equals when we die.
No death should be more honored — or ignored — than another.
The source code for MACRO SPITBOL contains extensive documentation. I have extracted the specification of the MINIMAL (Machine Independent Macro Assembly Language) and the specification of the OSINT (Operatint System INterface) and converted the plain text to HTML, resulting in what is now the “MINIMAL Reference Manual.
As part of this effort I wrote an introduction in order to give a sense of the flavor of the code. Here is that introduction:
The implementation of MACRO SPITBOL is written in three languages: MINIMAL, C, and assembler.
The SPITBOL compiler and runtime is written in MINIMAL, a machine-independent portable assembly language.
The runtime is augmented by procedures written in C that collectively comprise OSINT (Operating System INTerface). These procedures provides such functions as input and output, system initialization and termination, management of UNIX pipes, the loading of external functions, the writing and reading of save files and load modules, and so forth.
The implementation also includes assembly code. This size of this code varies according to the target machine. About 1500 lines are needed for the x86 architecture running UNIX.
This code provides such functions as macros that define the translation of MINIMAL instructions that take more than a few machine-level instructions, support for calling C procedures from MINIMAL, for calling MINIMAL procedures from C, for creating save files and load modules, and for resuming execution from save files or load modules.
To give some idea of the flavor of the code, consider the following simple SPITBOL program that copies standard input to standard output.
loop output = input :s(loop) end
By default, the variable input is input-associated to standard input, so each attempt to get its value results in reading in a line from standard input and returning the line as a string. The read fails if there are no more lines, and succeeds otherwise.
Similarly, the variable output is output-associated with standard output, so each assignment to output causes the assigned value to be written to the standard output file.
The osint procedure for writing a line is SYSOU. It is called from within SPITBOL as part of assignment, as shown in the follwing excerpt from the MINIMAL source:
* here for output association
asg10 bze kvoup,asg07 ignore output assoc if output off
asg1b mov xl,xr copy trblk pointer
mov xr,trnxt(xr) point to next trblk
beq (xr),=b_trt,asg1b loop back if another trblk
mov xr,xl else point back to last trblk
.if .cnbf
mov -(xs),trval(xr) stack value to output
.else
mov xr,trval(xr) get value to output
beq (xr),=b_bct,asg11 branch if buffer
mov -(xs),xr stack value to output
.fi
jsr gtstg convert to string
ppm asg12 get datatype name if unconvertible
* merge with string or buffer to output in xr
asg11 mov wa,trfpt(xl) fcblk ptr
bze wa,asg13 jump if standard output file
* here for output to file
asg1a jsr sysou call system output routine
err 206,output caused file overflow
err 207,output caused non-recoverable error
exi else all done, return to caller
From the OSINT C code (the C procedure name starts with ‘z’ since there is intermediate code (shown below) to call from MINIMAL to C at runtime):
zysou()
{
REGISTER struct fcblk *fcb = WA(struct fcblk *);
REGISTER union block *blk = XR(union block *);
int result;
if (blk->scb.typ == type_scl) {
/* called with string, get length from SCBLK */
SET_WA(blk->scb.len);
} else {
/* called with buffer, get length from BCBLK, and treat BSBLK
* like an SCBLK
*/
SET_WA(blk->bcb.len);
SET_XR(blk->bcb.bcbuf);
}
if (fcb == (struct fcblk *) 0 || fcb == (struct fcblk *) 1) {
if (!fcb)
result = zyspi();
else
result = zyspr();
if (result == EXI_0)
return EXI_0;
else
return EXI_2;
}
/* ensure iob is open, fail if unsuccessful */
if (!(MK_MP(fcb->iob, struct ioblk *)->flg1 & IO_OPN)) {
return EXI_1;
}
/* write the data, fail if unsuccessful */
if (oswrite
(fcb->mode, fcb->rsz, WA(word), MK_MP(fcb->iob, struct ioblk *),
XR(struct scblk *)) != 0)
return EXI_2;
/* normal return */
return EXI_0;
}
Here is the assembly code that is used to call a C procedure from MINIMAL. The code is for 32-bit X86
and is written using NASM (Netwide Assembler) syntax.
%macro mtoc 1
extern %1
; save minimal registers to make their values available to called procedure
mov dword [reg_wa],ecx
mov dword [reg_wb],ebx
mov dword [reg_wc],edx ; (also reg_ia)
mov dword [reg_xr],edi
mov dword [reg_xl],esi
mov dword [reg_cp],ebp ; Needed in image saved by sysxi
call %1 ; call c interface function
; restore minimal registers since called procedure may have changed them
mov ecx, dword [reg_wa] ; restore registers
mov ebx, dword [reg_wb]
mov edx, dword [reg_wc] ; (also reg_ia)
mov edi, dword [reg_xr]
mov esi, dword [reg_xl]
mov ebp, dword [reg_cp]
; restore direction flag in (the unlikely) case that it was changed
cld
; note that the called procedure must return exi action in eax
ret
%endmacro
...
global sysou ; output record
sysou:
mtoc zysou
As best as I can tell, I am in what I believe to be a unique situation:
I am the maintainer, sole developer, and probably the only active user of the programming language SPITBOL.
(If you know of anyone else who is maintaining an open-source implemenation of a programming language that has only one user, please let me know, via comments to this post.)
Let me explain.
In June of this year I took over maintainership of Macro SPITBOL. Mark Emmer had labored for almost a quarter century in this task. He kept Macro SPITBOL alive, and that is the task I face going forward.
Macro SPITBOL, the work of Robert B. K. Dewar and the late A. P. “Tony” McCann, is the best implementation of the SNOBOL4 language yet created. I believe it to be a remarkable accomplishment.
SNOBOL was created at Bell Labs in the early 60′s. The basic reference is The SNOBOL4 Programming Language, by R. E. “Ralph” Griswold, J. F. Pogue, and and I. P. Polonsky. It is known to SNOBOL4/SPITBOL folks as just “The Green Book,” due to the color of its cover. (Mark Emmer secured the rights to make it available, and the pdf for the book is freely above at the cited URL.)
SNOBOL was the first language to address processing strings and text in a serious way. It’s most notable innovation was the notion of “pattern.” As part of this, it introduced many primitives such as BREAK and SPAN. Those terms are now commonly used in many libraries and programs that process text.
SNOBOL was one of several languages widely taught in “Introduction To Programming” courses in the 70′s and early 80′s.Then — I think it fair to say — SNOBOL sank into obscurity.
Macro SPITBOL was created in the mid 70′s. Dewar and McCann finished their work by the late 70′s. I did the port to CDC 6600 in the late 70′s, and worked with Robert to do the port to the IBM/PC 8086 in 1983. Mark Emmer then took over the project, and did ports to Mac, Solaris, and various versions of Unix.
At most ten people worked on refining the SPITBOL implementation. I’m the only one still working on it. Mark lends a hand now and then, but more as an advisor than programmer.
Since taking over maintainership I have finished the Linux port (Mark had already done most of the heavy lifting). I started writing about SPITBOL on this b log to drum up interest, and I am actively working on the port to Apple’s OSX, to be followed by a port to the ARM architecture, so that SPITBOL can be made available on Apple’s ioS and Google’s Android operating environments (both use ARM chips).
Here is where the work stands:
In summary, though I know I have advanced the code, I have been a failure trying to drum up interest in the project.
What Next?
I am not giving up. I have several reasons to push on:
It is also evident that talking about SPITBOL is a thankless task for now, so I’m going to put off blogging, twittering and such, so I can concentrate on the coding, which after all is all that matters.
Most importantly, I believe that polishing the implementation and porting it to new environments is not enough.
The *only* way to move the project forward is to finish needed refinement and ports as soon as possible, and then to use the result to write applications in SPITBOL that demonstrate what can done when programming in SPITBOL.
I have a few ideas about useful applications, and hope to get to work on them as soon as possible.
We shall see…
Notes:
1. Can you name a widely-used contemporary programming language that still uses the 60′s software technology of reference counts to manage storage?
| M | T | W | T | F | S | S |
|---|---|---|---|---|---|---|
| « Jan | ||||||
| 1 | 2 | 3 | 4 | 5 | ||
| 6 | 7 | 8 | 9 | 10 | 11 | 12 |
| 13 | 14 | 15 | 16 | 17 | 18 | 19 |
| 20 | 21 | 22 | 23 | 24 | 25 | 26 |
| 27 | 28 | 29 | 30 | 31 | ||
The Wayward Word Press
Tuxer's
Welcome