Matt J. Gumbley | Website: http://www.gumbley.me.uk
Blog: On The Edge of Occam's Razor

The Psion-Forth Project

Table Of Contents

1 Introduction

 This project or information is dead. I cannot release any code or further information on it, other than what you'll find on this page. All communication regarding it will be silently deleted. Apologies.

This project is an attempt to port a version of the Forth programming language to the Psion SIBO architecture. There is already one version of Forth, but it isn't Open Source, and so can't be considered for any of my projects. I ideally want to be able to link this Forth into the PsiStack TCP/IP system, and provide sufficient hooks into the HWIF library as to be able to develop decent TCP/IP client applications with it.

The finished product will be released under the GNU General Public License. It should run on all Psion SIBO kit, although I'll only be able to test it on the 3c, the 3, and emulators.

1.1 Why Forth for SIBO development?

Forth is small, fast, and extensible. It's an excellent language for systems like the SIBO machines. Plus, it might stimulate development amongst those who can't obtain the C SDK, and those who won't touch OPL with a bargepole (like me).

1.2 Current status

 (As of 22nd April 1999)

I have no code available yet - I have plenty on disk here, but nothing ready to publish. I have taken the EXE model (dual segment) of hForth, converted it to build under Borland Turbo Assembler, and am integrating code that provides access to the SIBO console. This requires the building of a separate console/device library, which I'll test in a C harness before patching it into hForth. The hForth kernel seems to work OK so far - it boots as far as the console initialisation code, which breaks, and causes an OS panic. Hopefully, I've done the Turbo Assembler conversion 100% - any missing patches are likely to take a very long time to track down.

1.3 Acknowledgements

I'd like to thank:
  • Chris Jakeman, and the UK Forth Interest Group, for publicising this project in Issue 101 of ForthWrite.
  • The denizens of comp.lang.forth for advice on which Forth to choose.
  • Leo Brodie, Alan Wakefield, Elizabeth Rather and Edward Conklin for the books I've used for re-learning Forth.
  • Dr. Wonyong Koh, for hForth.

2 Which Forth to Port?

 I have considered these alternatives:
  • eForth, a small, 8086-assembly language Forth, ANS-aligned
  • pForth, a medium-sized ANS-Forth, written entirely in C.
  • hForth, a small ANS-Forth, derived from eForth.

2.1 eForth

 eForth version 1.0 comes in assembly source form, for the 8086. It is small model, CS=DS=ES=SS, rendering it unsuitable - without modification - for SIBO, which requires CS != DS=SS=ES. Also, eForth is not ANS Forth. While this doesn't bother me unduly, I'd like to work on something that's standard. I'd rather not hack assembler - although in the end, it's the best way.

2.2 pForth

 Rather than having to hack assembler, I'm in favour of pForth. The problem with this is that the TopSpeed C Compiler used in the Psion C SDK cannot handle the main switch() statement of the interpreter. I thought about getting round this using another compiler for that module, and patching it in to the rest of the object code. Either that, or ditch TopSpeed altogether for this project, and build it using gcc, or bcc.

This is known as a non-trivial exercise, and since this is Yet Another Spare Time Project, of which I have virtually none, I've abandoned pForth, leaving me with....

2.3 hForth

An ANS-aligned Forth, based on eForth, written by Dr. Wonyong Koh. The version I'm working from is version 0.9.9, for the 8086/DOS EXE Model. This has a separate code segment, and is ideal for SIBO. The code is in MASM format, which gives me a headache, since I don't own MASM.

It should build easily under Borland Turbo Assembler, but it doesn't.

Since the hForth code has to be linked with Psion's SIBO C Startup code, and several library routines, the hForth kernel is not the first object file - this is reserved for the startup code. Now, under the SIBO C SDK/TopSpeed Linker, all object modules' data segments are grouped under DGROUP, and are fixed up so that references relative to the start of each module refer to their correct place in the full DGROUP segment. Not so with the Turbo Asseembler/Linker! It seems that this linker does not fix up correctly, in that all references to the data segment in a given module are kept as relative to the start of that module's data segment (i.e. 0000, not start-of-this-data-segment-in-DGROUP). So, I've had to manually go through all the hForth code, and explicitly specify DGROUP segment overrides.

This took ages - both to discover, and to do. Apparently, the Turbo Assembler ignores ASSUME DS: DGROUP in MASM mode, but honours it in Ideal mode. I know F.A. about Ideal mode, have no desire to learn, and haven't time to - this code is foreign enough without worrying about whether I've ported it to (effectively) a different language.

To do this patch, I built hForth, redirected all errors to a file, and used a Perl script to go through the list of errors, the map file, and the source, and patch in DGROUP overrides into the relevant source lines, in both code and data segments. I also did some by hand. This is rather scary, and if hForth doesn't work when I've finished, this is probably where the error lies.

3 Download

This isn't available for download yet.

4 Mailing List

 There isn't one, although I'd be very happy to set one up (and will probably do so) when I have something we can actually use!
(C) Matt J. Gumbley 1998-2005 - All Tights Reversed