[Image] [ImageMatt J. Gumbley - http://www.gumbley.demon.co.uk
[Ceci n'est ce pas Matt Gumbley]
The Psion-Forth Project
Updated Thu Table Of Contents
Feb 17
20:48:13 2000 * 1 Introduction
o 1.1 Why Forth for SIBO development?
o 1.2 Current status
Site Map o 1.3 Acknowledgements
> Site Home * 2 Which Forth to Port?
page o 2.1 eForth
> Matt's home o 2.2 pForth
page o 2.3 hForth
> Angela's * 3 Download
home page * 4 Mailing List
> Our Wedding
Pages 1 Introduction
Personal This project is an attempt to port a version of
> Online CV the Forth programming language to the Psion SIBO
> Family architecture. There is already one version of
history Forth, but it isn't Open Source, and so can't be
> My Day Job considered for any of my projects. I ideally want
to be able to link this Forth into the PsiStack
Projects TCP/IP system, and provide sufficient hooks into
> Latest News the HWIF library as to be able to develop decent
> The Crypt TCP/IP client applications with it.
> (Old, Dead
Projects) The finished product will be released under the
Miscellaneous GNU General Public License. It should run on all
> SigChange Psion SIBO kit, although I'll only be able to test
> Home Page it on the 3c, the 3, and emulators.
Sync
> HTML Macro 1.1 Why Forth for SIBO development?
System
Psion EPOC Forth is small, fast, and extensible. It's an
> Overview excellent language for systems like the SIBO
> Mixed machines. Plus, it might stimulate development
Language amongst those who can't obtain the C SDK, and
Programming those who won't touch OPL with a bargepole (like
> GDB Debug me).
Stub
> hForth Port 1.2 Current status
> Disassembler
Psion SIBO (As of 22nd April 1999)
> All SIBO
projects are I have no code available yet - I have plenty on
in disk here, but nothing ready to publish. I have
> The Crypt taken the EXE model (dual segment) of hForth,
Linux converted it to build under Borland Turbo
> Toshiba Assembler, and am integrating code that provides
40xx & Linux access to the SIBO console. This requires the
> Network-RS232 building of a separate console/device library,
Bridge which I'll test in a C harness before patching it
> Psion into hForth. The hForth kernel seems to work OK so
Protocol far - it boots as far as the console
Analyser initialisation code, which breaks, and causes an
> Serial Line OS panic. Hopefully, I've done the Turbo Assembler
Analyser conversion 100% - any missing patches are likely
> Work on to take a very long time to track down.
plptools
> Psion .img 1.3 Acknowledgements
tools
> Happy I'd like to thank:
Badger Linux
> Linux Psion * Chris Jakeman, and the UK Forth Interest
Link Ideas Group, for publicising this project in Issue
Amateur Radio 101 of ForthWrite.
> Amateur * The denizens of comp.lang.forth for advice on
Radio which Forth to choose.
Software * Leo Brodie, Alan Wakefield, Elizabeth Rather
and Edward Conklin for the books I've used
Popularity for re-learning Forth.
* Dr. Wonyong Koh, for hForth.
> accesses so
far.. 2 Which Forth to Port?
[Image]
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!
Matt J. Gumbley - matt@gumbley.demon.co.uk
(
geocities.com/tutorman_2000)