Tag Archives: linux

FRIBBLE, a SPITBOL program to play word games such as Word With Friends, now available

The FRIBBLE project is pleased to announce its first release V17.1.30, available at Fribble Project.

FRIBBLE is written in SPITBOL, and uses a brute-force approach, trying all possible moves, to play WWWF.

Fribble can be run in three ways: to play against itself, to play against you, or to help you play a game with a foe, with Fribble finding your moves.

The code speaks for itself. Speaking for my self, I can say that I have never had more fun writing a program than I have had writing FRIBBLE.

FRIBBLE is also my first program inspired by an election.

I was an obsessive follower of the recent presidential election, spending more time than I care to admit on Twitter, reading blogs, listening to podcasts, and so on.

After the election, looking for a more productive and entertaining form of amusement, I started playing Words With Friends, an online version of Scrabble. My foe was a fellow IBMer and friend who said he was quite good at WWF.

Indeed he is. We have played many games and I have yet to beat him. Often his score is 50% higher than mine.

Soon after I realized I was unlikely to ever win a game against him, I though of using my programming skills to see if I would write a program that could play WWF.

Fribble, representing just over two months of the most fun I have yet had writing a program, is the realization of that goal.

What has made the writing of Fribble such fun is the realization that it is as close to an ideal demonstration of SPITBOL as I have yet seen. Everyone knows about games such as Scrabble and WWF, and dealing with strings, words, lines of text, dictionaries, and all that such games involve, is the perfect grist for SPITBOL’s mill.

Though the program is largely done, I plan to continue work on it by using it as a way to teach SPITBOL as a first, or at least early, programming language.


SPITBOL for OSX is now available

The SPITBOL project is pleased to announce that an implementation for OSX is now available, and can be found at github.com/spitbol/spitbol.

SPITBOL now supports the use of the gas (GNU as) assembler to translate the MINIMAL source code. This is now the default translator used for Unix and OSX.

Executable binaries:

./bin/sbl_osx OSX SPITBOL (64 bits)

./bin/sbl_unix Unix version (64 bits)

./bin/sbl_unix_32 Unix version (32 bits)


./docs/green-book.pdf The SNOBOL4 Programming Language, Griswold, et. al.

./docs/spitbol-manual.pdf SPITBOL User Manual, Emmer and Quillen

./demos demonstration programs from the SPITBOL User Manual

SPITBOL is licensed under the GPL (v2 or later) license. All code needed to build the system is included in this repository.

To build spitbol (./sbl):


make osx

make test_osx

make unix

make test_unix
See readme.txt for instructions on interpreting the test output.

SPITBOL Status Report: NASM to GAS conversion complete

The conversion of asm.spt to generate gnu assembler (gas) code instead of nasm format is complete.

For those who know of such matters, I now generate att syntax, as it’s easier to generate from a program than intel syntax.

A few hours ago I finally got a compile with no errors, so I could run the executable.

It’s still dying early on. The good news is that with the use of gas I can now use ‘-g’ for debugging and get useful information from the ‘ddd’ debugger.

Simply put, I have debugging resources at hand that should suffice, so it’s just a matter of slogging along until its done. I don’t think it’ll take that long.

If you want to follow the details, or track my work, checkout branch ‘gas’.

I’ll keep you posted.

On the Merit of Transparent Console Windows in Ubuntu Linux

I use Linux Mint — a variant of Ubunbu Linux — for my day to day programming. Here’s a screen shot of what my screen usually looks like:

Usual mode - two console windows.

Usual mode – two opaque terminal windows.

Above you seen two terminal windows. I use the KDE Konsole program; this is my normal mode. I do edits in the right window. I use the left window to view output, search files,
and so forth.

Here’s another mode I’ve just started using:

Screenshot-transparentTwo opaque terminal windows with transparent window in middle

See the difference?

There’s a new terminal window in the middle, but it’s transparent — you can see through it to the windows below.

Now I had known about transparent terminal windows for some time, but I had never never gotten around to trying them. I was happy with my usual mode of just two opaque windows.

A couple of weeks ago I updated my desktop to use the latest version of Linux Mint. Though Mint comes with the Konsole program, you have to dig around in the menus to find it.
There’s always a quick link to a terminal program in easy view, but it’s not for Konsole.

It turns out this version of Mint configures that default terminal program to use a transparent screen. So I tried it, and finally appreciated the advantage of the

Though the transparency is a nuisance when just editing text, it’s great for other situations.

For example, if I need to do a small task, and don’t want to disturb my two normal windows, I just open up a transparent window.

The main advantage I’ve found is that if I’m looking at a web page with instructions on how to do something, then I can open a transparent window, view the instructions
through the window, and enter them directly with much less chance of error.

Unix SPITBOL 13.05 Released, With Support for Unicode

The SPITBOL project is pleased to announce that Unix SPITBOL 13.05 is now available.

It can be downloaded from http://spitbol.googlecode.com/files/spitbol-13.05.tar.gz.

This release includes versions of SPITBOL for both ASCII (8-bit characters) and Unicode (32-bit characters).

The Unicode version of SPITBOL (uspitbol) uses 32-bit characters internally. Character strings are converted from UTF-8 encoding to 32-bit characters when input from the command line, the operating system environment, a pipe, or a file opened in line mode. Character strings are converted from 32-bit characters to 8-bit characters in UTF-8 format when written to a file opened in line mode, a pipe, or when passed as an argument to an operating system procedure.

Program source files, which are read by SPITBOL in line mode, may thus contain UTF-8 format Unicode characters in strings and comments. Identifiers are still restricted to ASCII.

Unix SPITBOL 13.01 Released

The SPITBOL Project is pleased to announce that Unix SPITBOL 13.01 is available.

It can be downloaded from Github: HARDBOL/SPITBOL:

13.01 tar.gz

13.01 zip

This release supports floating-point arithmetic and save files. Load modules and the loading of external functions are still not supported.

SPITBOL Update: SPITBOL X86-64 can compile “hello world”

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.


SPITBOL Status Report

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.

  • Pages

  • February 2017
    M T W T F S S
    « Jan    
  • RSS The Wayward Word Press

  • Recent Comments

    dave porter on On being the maintainer, sole…
    daveshields on On being the maintainer, sole…
    Paul Tallett on On being the maintainer, sole…
    mrrdev on On being the maintainer, sole…
    KT on On being the maintainer, sole…
  • Archives

  • Blog Stats

  • Top Posts

  • Top Rated

  • Recent Posts

  • Archives

  • Top Rated