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

Table Of Contents

1 The psion-c Project

 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.

1.1 Latest News!

 15th March 1998: DJ Delorie's 16-bit gcc patch may prove very useful. I'm looking at using gcc, with this patch (and finisheing it off). Also, take the work done for the bcc toolset, split it away from bcc, add it to gcc, work out how I changed the original bcc compiler, and add this as a set of diffs, to the latest version of the bcc compiler. Ask the bcc team if they'd accept my changes, so that we can benefit from their ongoing developments. Also, need to add a processor to munge the Psion header files and libraries.

Anyone fancy building Linux for the SIBO platform?

Around October 1997: temporarily halted work on the bcc compiler. Adding the #pragma parser was proving tricky, and I've got other things to do... like moving house! 13th October 1997: Dave Walker's website address changed. It's here.

5th September 1997: Psion Software have granted us permission to redistribute the header files from the SIBO C SDK. Here's the email I received from Ali Manson: 

Date: Thu, 04 Sep 97 13:35:40 GMT
From: "Ali Manson" 
To: "Matt J. Gumbley" 
Subject: Re: Redistributing C SDK headers...

     
     Hello Matt
     
     Apologies for the delay. We have no problem with your distributing the 
     header files.
     
     However, the header files must be distributed *intact*. As such, this 
     means that the #pragmas will remain. I wouldn't have thought that it 
     would be too much trouble to have your compiler parse out the 
     #pragmas.
     
     If you can accept this simple restriction, you have our permission.
     
     with best regards
     
     Ali
This means we'll have to modify the pre-processor to handle #pragmas - looks like a good time to start the register allocation code! I'll have a new release of the compiler package out sometime in the next month, containing the header files, and any addition bits I add....

We've also got permission to residtribute ld86-compatible libraries, so long as the copyright remains intact....

1.2 Availability

Downloadable development snapshots, available from ftp://ftp.inet.alsutton.com/pub/:
21st March 1997, Snapshot 4

Soon to be ported to DOS!! Soon to incorporate the c86 compiler and pre-processor!! Soon to incorporate nasm!! And now.... IT WORKS!!! (although you have to use RunImg).

You may need to hold down the right-shift key and click the above links to download the files successfully using Netscape.

There are a number of possibilities for this project.

1.3 Porting 'bcc' and its toolset

 I have started work on converting the GPL'ed 'bcc' K&R compiler, as used in the Linux-8086 project. It uses versions of the as86 assembler and ld86 linker to produce its executables, which are in a variant of the 'a.out' (OMAGIC) format. The whole package will be interchangeably referred to as "the Software Development Kit (SDK) or "the toolset".

The toolset will have to be modified to produce executables suitable for EPOC. There are two things that need to be done before programs built using this toolset can run on the Psion:

  • Produce the right executable format. The EPOC executables are in Psion's '.img' format. A converter has been written ('imgconv') which takes the output from 'ld86' and converts it to .img format. This is not yet fully working properly.
  • Allow parameter passing in registers. Traditionally, C compilers call functions by placing parameters on the stack, and calling the function entry point. The function then retrieves the parameters from the stack, does its thing, and places any return value back on the stack. Calls into the EPOC operating system however require values to be loaded into registers, and an software interrupt generated. The way to do this is to specify the operating system calls in a #pragma, which gives the name of the OS function, its parameters - and which register should be used for which parameter - its entry point or software interrupt number, and which registers are trashed by the OS function. 'bcc' does not (yet) support this. This is also a very useful source of optimisation! I'd like to support the #pragma syntax and semantics of Psion's own version. Until then, we've got to make do with a stub library. As we have permission to use verbatim copies of Psion's header files, the pre-processor must at least be modified to ignore the #pragma's.
Also, I'd like to be able to produce pure small-model executables. This is where there are two process memory segments, text (machine code) and data (variables). Text is pointed to by the CS segment register, and the data pointed to by the other three segment registers, which all hold identical values, i.e. DS=ES=SS.

At the moment, 'bcc' assumes CS=DS=ES=SS. (AFAIK) If the code generated does not mess with the segment registers (AFAIK, it doesn't) it might be straightforward to set CS and DS=ES=SS differently in some startup module.

With the 0.05 release comes the inclusion of Psion's header files. There is also a version of the C library from the Linux-8086 project. Several publically-available sources for the EPOC pragma information have been used in the creation of the stub library. Hopefully, we'll be able to phase this out soon.

The compiler runs on Linux 2.0 and MS-DOS (with the addition of a suitable DPMI server, Windows 95 will do - see www.delorie.com for more details).

The first development snapshot of my work so far was created on Monday 20th January 1997.

There were several questions I wanted to ask about 'bcc'. Fortunately, Andrew Lord started asking the right people the right questions before I got chance to. Here's a reply to his post on comp.sys.psion.programmer: 


Subject: Re: Freeware C Compilers for the Psion .... 
Newsgroups: comp.sys.psion.programmer
References: <32DCA7AF.F5D@tertio.co.uk>
Distribution: 

I'm glad there's some interest in this... 

Andrew Lord (Andrew_Lord@tertio.co.uk) wrote:
: I'm putting out some feelers about *freeware* 8086 C compilers for the
: Psion. This was prompted by someone mentioning 'bcc' in this group.

That was possibly me. I'm modifying bcc to produce Psion executables. It
satisfies the register and model requirements.

: BTW: Does anyone know *exactly* what are are the requirements of a
: compiler regarding the use of the ES register? Because I'm a bit vaugue
: about it and I've heard different descriptions? 

Me too. Could somebody clarify this. I'm assuming it's forbidden to do anything
with any of the segment registers.

: I've posted to comp.os.minix and to a member of the  Linux-8086 mailing
: list and pasted the responses at the end.

Excellent. I was going to do this, and you've saved me the bother. Thank you.

: Because the sources for the bcc compiler are available we could probably
: get something going on just about any platform with a decent C compiler.

I've built the compiler, assembler, linker and various other tools from the
archive of the Linux-8086 group. A few loose ends needed tying up, and some of
the advertised command line options weren't working. They are now.

I'm running the compiler on Linux (Slackware 3.1, if you need to know).

: Also there is a Minix (another mini-unix) which can also run on the
: 8086. The sources for the kernel is available but not the C-compiler.
: (Wich probably runs under Minix and not DOS). Its all copyrighted by
: Prentice-Hall and can be used for free stuff but I don't know whether
: you could develop shareware using it....

Minix is a bit old. I'd go for either the DOS or Linux machine, cross-compiling
for the Psion.

: Two things to bear in mind are :
: 
: 1. I don't want to lose 64K (or 128K) everytime I run a compiled
: program, we'd have to think seriously about the PLIB libraries or
: implementing overlays (ala OPL).

I'm sorry, I don't quite follow you on this point..

: 2. The imminent arrival of EPOCH32 ??!?!?

I've invested a lot of cash in a new 3C. I'm not terribly worried about EPOC32
just yet. I just want a set of free development tools.

: Andy L.
: Andrew_Lord@tertio.co.uk

: To Alan Cox on the Linux-8086 mailing list :
: (bcc is the compiler for the Linux-8086/OS)
: 
: > what state is 'bcc' in?
: 
: Fairly good

I'd agree with this. Bear in mind, it's a K&R compiler, which can strip off
ANSI prototypes. There doesn't seem to be a lot of optimisation going on at the
moment. I'm looking into this.

: > Is bcc 'finished' in the sense that it can be used as a cross-compiler
: > to compile for a hand-held PDA (that uses the 8086). I guess I would
: > have to find/write the libraries myself.
: 
: You can probably use a lot of the small C library we have built up for
: it.

Yes, I'm using it as a cross-compiler. If the C library is in the ROM of the
3c, then my version will be able to generate inline interrupts to access it. If
the C library is statically linked with the applications we produce using bcc,
then Alan is probably quite right, although I haven't looked much at their
small C library.

: > Do you know of any other quality free C compilers for the 8086? No

Small C has been ported, and I believe Sozobon C still exists. Forget Small C,
as it's not even up to K&R standards. I can't recall whether Sozobon C had any
optimisation...

: > One requirement is that generated code must not alter the ES register. 
: > (OR something like that) 
: 
: It assumes CS=DS=ES

Which is just excellent...!

: [ Me- Does this mean that you cant use 64K Code + 64K Data without
: heartarche?]

Correct. It is "pure small model". You can ask EPOC for more memory in other
segments, I believe, and you can always segment your code into .DYLs, which is
probably what we'll have to do for the Psion-Java and Psion-TCP/IP projects.
See home page http://www.geocities.com/SiliconValley/9577/ for more details.

: > On a DOS box - could I compile the bcc sources using djgpp and then 
: > start generating 8086 code?
: 
: Probably. It ought to compile with most compilers. If you build it with
: a good 8086 compiler it will fit in under 64K and run on the PDA - the
: optimisation in it currently isnt up to self compiling into 64K

He's right, Jim :)
Since I'm only interested in pursuing the Linux-hosted compiler, I won't be
attempting to port it to DJGPP, for instance. I'll put at archive of my current
development snapshot on my web page, sometime soon.

: Reply of post to comp.os.minix (I forgot to mention the ES constraint
: thought)
: 
: =====================================================================On
: Tue, 14 Jan 1997, Andrew Lord wrote:
: 
: > I am looking for a freeware C compiler that can produce code for the
: > 8086 (on a hand-held PDA). So a few questions about the Minix C compiler > 
: > 1. Can it produce code for the 8086 (actually the NEC V30 a compatible 
: > chip with a few extra instructions) ?
: 
: Yes, the version distributed in the i86 Minix distribution produces 8086
: object code.

In the usual Minux 'a.out' format, as does bcc - at the moment.

: > 2. Can I modify the compiler source/libraries and distribute a resultant 
: > cross-compiler for free? (I guess - yes )
: 
: I think the compiler sources have never been released, only the binary
: is distributed with Minix. However, source for all the Minix libraries
: is distributed.

Well, that's that particular avenue of investigation closed then!

: > 3. Could the above cross-compiler be used to produce commercial software 
: > (for the handheld PDA)?
: 
: I suspect not, at least not without obtaining permission. Somewhere in
: the Minix package there should be some info on the licensing.  Or there
: may be something in the /pub/minix tree on ftp.cs.vu.nl. If it 
: isn't there, write to Andy Tanenbaum (ast@cs.vu.nl) and ask. I know the
: compiler is copyright by his university in the Netherlands, and it took
: him some effort to get permission to distribute it with Minix. It was 
: being sold commercially by UniPress (?). This is a separate license from
: the permission given to distribute Minix itself, by Prentice-Hall. My 
: impression is that Andy would like to make his work (Minix and the
: compiler) as widely available as possible, but that the copyrights are
: owned by institutions with lawyers :-(.

Sorry, not interested in the Minix version then.

: > 4. If No what about if I write my own libraries (unlikely!) ?
: 
: I don't know.
: 
: > 5. Do you know of any other quality freeware C compilers that run on DOS 
: > (or UNIX where the compiler source code is available) a that can target
: > an 8086?
: [I forgot to mention the ES constraint!]
: 
: I am sure there are some, but why not just look for an older version of
: a Microsoft or Turbo C compiler for MS-DOS. I don't know what things are
: like where you are, but I found locally, at what we call a "garage sale"
: a second-hand copy of a 1987-vintage Turbo C with its single manual and
: both floppy disks for $5. It's a great tool for small programming
: projects, such as working out solutions to student problems or other
: project with a few to a few dozen pages of source code. If you are
: trying to do something professional with hundreds of pages of source
: code you should just pay for professional tools. 

Sorry, no commercial compilers need apply :)

: That said, I believe there is some kind of project to make a downsized
: port of Linux to 16-bit processors. I don't know who is doing this, or
: why -- I suppose possibly for projects like yours. This must require
: some way of getting 16-bit code out of gcc.  Also, up until Mark
: Williams Company went out of business a year or so ago they were
: supporting both a 16-bit and a 32-bit version of the Coherent Unix
: clone.  I think 16-bit Coherent itself required a 286, but I would be
: surprised if ordinary user programs contain code that wouldn't run on an
: 8088. There is still some activity on the comp.os.coherent newsgroup,
: maybe you could buy a used copy there. 

Again, it's commercial. Je ne touchez avec une barge-pole.

: Albert S. Woodhull

: >>>>> "AL" == Andrew Lord  writes:
: 
: AL> I am looking for a freeware C compiler that can produce code for the
: AL> 8086 (on a hand-held PDA). So a few questions about the Minix C
: compiler
: 
: Well, I don't know much about the minix compiler but...
: 
: AL> 4. If No what about if I write my own libraries (unlikely!) ?
: 
: Check out the gnu libc at ftp://prep.ai.mit.edu/pub/gnu.
: 
: AL> 5. Do you know of any other quality freeware C compilers that run on
: DOS AL> (or UNIX where the compiler source code is available) athat can
: target AL> an 8086?
: 
: Check out lcc, a retargetable portable ANSI C compiler which is freely
: available on http://www.cs.princeton.edu/software/lcc/.

Bingo! Nice work, Andrew!

: scotth@visix.com (Scott Hofmann) 

If I may, I'd like to place the result of your search on my experimental
Psion-C web page, at:
http://www.keele.ac.uk/depts/cs/Staff/Homes/Matt/psion/psion-c.html

This has saved me a lot of work. Let me know next time you're near Keele, UK -
I owe you several beers!
-- 
Matt Gumbley: Research Assistant, Computer Science, University of Keele
          matt@cs.keele.ac.uk / Room 106 / +44 (0)1782 583438

1.4 Porting 'lcc' and its toolset

 So, it may be based on 'lcc' instead. The home page for this is at: http://www.cs.princeton.edu/software/lcc/

'lcc' is attractive since it builds ANSI C, but AFAIK, does not have an 8086 code generator, and so would involve a lot of work.

1.5 Collaborating with the CPOC developers

I have received email from Keith Walker, one of the developers of the CPOC project, suggesting we should pool our resources and collaborate on developing a SDK using our combined tools. CPOC is a Psion-hosted ANSI C compiler, although there are versions available which run on Windows 95/NT and Linux, amongst others.

Their system is very attractive, since it is an ANSI C compiler, with optimisation. There is an 8086 generator. However, there is no support for EPOC's register-based calling convention, and their libraries may be older than mine. They do support .img format executables as the native output of their modified 'ld86' linker, rather than running the a.out executables through a converter, as I do. The advantage of my arrangement is that I can automatically make use of new versions of 'ld86', although it's unlikely I'd need to. Their advantage is speed. However, techniques they've used in their linker might be useful in my converter. We'll see.

The Walker Brothers' compiler toolset is a mature, portable system. A merger of their pre-processor, ANSI C compiler, some of my bolt-on tools, libraries, headers, startup code and debugging tools might result in a very useful and functional development environment.

I'll keep you posted.

The CPOC system is described in detail at their web site.
(C) Matt J. Gumbley 1998-2005 - All Tights Reversed