• Please review our updated Terms and Rules here

Powertran Cortex

Ritchie C compiler port

Ritchie C compiler port

Just a quick progress report. The port (as a cross compiler for now) is progressing nicely. Back then software packages did not come with test suites, so I use the Xinu source for that. The Xinu source consists of many short files (often only 30..70 lines), with one or two functions each. This makes it feasible to inspect the compiler assembler output and match it against its C source.

I'm working from the 2.11BSD version of the compiler, which was maintained till the early 90's: by and large it is a C89 compliant compiler.

Just to give an idea of where it is at, please find an example compilation attached. Note however that so far I have mostly looked at working with 'int', stuff related to e.g. long or float does not work at all yet.

Paul
 

Attachments

  • ritchie.zip
    1.4 KB · Views: 2
Summary for posterity of some recent e-mails

Summary for posterity of some recent e-mails

Dave supplied a C99 demo project for the Cortex, using asm990, lnk990, and bin990 to create a Cortex cassette image.

====

Hi Stuart,

For what it's worth, I tried the demo with 'UNIT 2' and 'UNIT -1' for
RS232 only and it did display text on the terminal (but without cursor-control). I did this as I thought your set up is like this?

Also, if you remove the -x option from the bin990 utility, then it will generate pure binary machine code instead of a cassette image. Perhaps this would be useful with your other 99xx hardware? You would have to modify the putchar/getchar assembler routines in CortexRTL.asm, but I'm sure you're that's no problem for you.

Dave.

====

C99 is essentially Small C ported to the 9900: http://en.wikipedia.org/wiki/Small-C, there's links to resources from there.
I still have the original articles from Dr. Dobbs somewhere, if need be I can scan those (but they are about the 8080 version).

In related news, I'm still making progress with the Ritchie compiler. I've now succeeded in compiling several files from Xinu (in fact all the material from chapter 4 of the 1984 version of the Xinu book: the process queue). The output code seems about equally dense as pdp11 code (fewer addressing modes make the code longer, but more registers make it shorter, it seems to balance out).

Paul

====

Stuart queried if there was a switch to make the .obj file from lnk990 absolute rather than relative. Dave replied:

The asm990 and lnk990 are from Dave Pitts and modified by me for DOS. The demo.obj is created by linking the relocatable asm modules to a single relocatable object. I asked Dave Pitts how to get an absolute file from that instead (ie the same question you have) and he said in a TI990 the operating system loads it at run time and assigns the load address at that time. Since it's a multi tasking OS, the programs have to be relocatable.

So he gave me a copy of what the OS does and my bin990 is based on that. I tell it the load address via the command line and it builds the executable as if it was about to be run by the TI990 OS.

====

Paul said:

"a TI990 the operating system loads it at run time and assigns the load address at that time"

That is what EVMBUG on the breadboard does as well: you pass an absolute load address to the LMC command and it relocates the .obj as part of the loading.
 
Just a quick progress report. The port (as a cross compiler for now) is progressing nicely. Back then software packages did not come with test suites, so I use the Xinu source for that. The Xinu source consists of many short files (often only 30..70 lines), with one or two functions each. This makes it feasible to inspect the compiler assembler output and match it against its C source.

I'm working from the 2.11BSD version of the compiler, which was maintained till the early 90's: by and large it is a C89 compliant compiler.

Just to give an idea of where it is at, please find an example compilation attached. Note however that so far I have mostly looked at working with 'int', stuff related to e.g. long or float does not work at all yet.

Paul

Looks good, Paul!

The compiler certainly seems to produce some decent code, especially in terms of using the addressing modes.

Great work so far!

Dave.
 
Ti-c

Ti-c

Just received a reply from Alan Beard. He attached the source to TI-C to his message. Had a quick look and it seems to compile under gcc with only a little fiddling. It generates much better code than Clint Pulley's C99 and seems to do most of C89 sans longs and floats. Like C99 it is a single executable that outputs assembly. The output seems compatible with asm990.

I would like to have this stuff up on the whtech site. Does anybody here know how to get in touch with the whtech maintainers?

Paul
 
I can make sure it gets up onto WHT. I believe Stuart can as well. This is very good news, as Al's been out of contact with the TI community for a long while. I bought his Fortran99/Fortran9640 program many years ago. It was a nice implementation of Fortran.
 
This is very good news, as Al's been out of contact with the TI community for a long while. I bought his Fortran99/Fortran9640 program many years ago. It was a nice implementation of Fortran.

That may become available for posterity as well. Al wrote:

Thank you for your letter of Dec 31, 2013. I have been a bit busy so did not have time to respond.

I have attached the last build I did for the TIC C compiler, it was about 20 years ago. Unfortunately I lost the source code for the companion TASM assembler. Much of the work for the TIC C compiler was based on the public domain 68000 C compiler that was in circulation at the time (even though it was a bit buggy). Paul Charlton at the time sent me some code he was working on from the same source baseline that was helpful, as well as Clint Pulley's testing it for me.

The 99 FORTRAN source code will take me a little longer to get together. The build is much larger and includes many function libraries, a lot which were contributed by Elmer Clausen.

I think Al more than deserves to be inducted into the TI hall of fame (http://www.ti99hof.org/).

Paul
 
I fully agree there! He was a great long-term supporter of the TI, and the fact that he kept copies of most of his code preserved says volumes of good in addition to what was already known! Let me know how you want to transfer the files and I'll arrange to get them up on WHT. We might also want to put some kind of message from him with the data to show that he's given his permission to post it.
 
Ti-c

Ti-c

Let me know how you want to transfer the files and I'll arrange to get them up on WHT.

Thanks for the offer! The files are with Don O'Neil of WHTech and he has promised to have them uploaded later this week.

Paul
 
Has somebody given him the "lost" issues 1, 5 & 8 of the user magazine ?

I've also got all the 5.25" disk images and scans of documentation from MPE that I've done so far.

Jim
 
Thanks Paul. If/when you have 5 minutes spare, could you do a step-by-step of how to compile a simple "hello world" program that can be assembled to run on the 9995 breadboard? I see the XOPs for input and output are already there, but I'm a little stuck as to where exactly to start.

Thanks to Al as well. Found a little more about him on [http://old-computers.com/museum/forum.asp?c=236&st=1] - search for his name on the page.

Stuart.
 
TIC step by step

TIC step by step

That link is what put me on Al's trail: there're only a few Beards in Franklin, MA.

Doing a straight "hello, world!" is a bit hard, because there is no standard library with printf in it; even a simple printf is 1..2 KB. Instead I have simple program that tests both input and output.

So, start with the following file, and call it 'test.c':
Code:
char s[81];

main()
{
  while( gets(s) ) {
    puts(s);
    putchar('\n');
  }
  return 0;
}

This gets a string from the keyboard (and accepts editing with backspace, ctrl-h) and then prints that same line back to the user. If you type a ctrl-z the program exits (see the C99 manual for details, I used those routines as a basis). Compile this C program with TI-C to an assembler file:
Code:
./tic test.c
TI-C will place the output in a file called 'test.S'. Now assemble this file to an object file:
Code:
./asm990 -o test.obj test.S
The runtime routine is supplied with the source and is called crt0.S. Also assemble the runtime routine to an object file (of course you need to do this only once, the resulting object file is the same for all projects):
Code:
./asm990 -o crt0.obj crt0.S
Next link the two parts together, taking care that crt0.obj comes first.
Code:
./lnk990 -o final.obj crt0.obj test.obj
The resulting 'final.obj' file is ready for downloading to the breadboard, were it not for the fact that it expects an object file with '\r' line endings and what we have produced has '\n' line endings (on linux and osx, haven't tried on windows). This can be fixed by a little tool 'flip':
Code:
./flip <final.obj >final.lmc
The 'final.lmc' file can be downloaded to the breadboard, using the LMC command. For that, reboot the breadboard, type 'A' to get the start-up menu and select '1' from that menu for EVMBUG. At the MON? prompt, type (note the use of uppercase):
Code:
MON? LMC 8000
EVMBUG will respond with 'Are you ready (Y/N)?' and type Y (again this has to be an uppercase Y). Now tell your terminal emulator to send the file 'final.lmc' to the breadboard. Once the file has been received, set the internal registers using the IR command:
Code:
MON? IR
WP ???? F000
PC ???? 8000
ST ???? 0
After typing each register value, end with a space to move to the next register, the enter key finalizes the command. Finally the progam can run, using the 'EX' command:
Code:
MON? EX
If all went well the code should run as expected.

Note (1)
The source code for the 'flip' build tool is:
Code:
#include <stdio.h>

int main()
{
  char c;
  while( (c = getchar())!=EOF ) {
    if( c==0x0a )
      c = 0x0d;
    else if( c==0x0d )
      c = 0x0a;
    putchar(c);
  }
  return 0;
}
I think I need to do a ROM with EVMBUG modified to accept '\n' and perhaps also '\r\n', just to remove this annoying build step which will undoubtedly confuse the hell out of first time users of the breadboard system.

Note (2)
I have found my fresh build of TI-C to have a crash prone optimizer. To disable the optimizer, compile with the -O flag (see manual, -O means switch off, +O means switch on to TI-C). Perhaps Al's 20 year old win binary does not have this problem.

Note (3)
The compiler probably needs some TLC to make it fully usable. I found that static functions have their names preceded by a hash ('#') in the assembler output and asm990 does not accept this. In my fresh build calling a function pointer seemed to generate the wrong code. Modifying the main routine to automatically call asm990 and lnk990 after compiling also makes it a lot more user friendly. Personally, I'd like to finish the Ritchie compiler port first, so if somebody else feels called to make some touch ups to TIC, feel free.

Note (4)
If somebody needs C source for a simple version of 'printf', I can post one on request.

Sorry for an overly long post. Let me know if you get stuck somewhere and I'll post further instructions. Perhaps in due course this material could make an interesting additional page on your website.

Paul
 
RIP Neil Quarmby

RIP Neil Quarmby

sadly I have to report that one of the people that made the Cortex possible, Neil Quarmby lost his battle against a brain tumour on Friday and passed away.
Rest in peace Neil
 
Ritchie C compiler port

Ritchie C compiler port

I'm happy to report that the compiler port has now sufficiently progressed that it can compile a 200 line C program correctly: printf is now working. The output code is about 1.3 kb, so using some very rough arithmetic the 4,000 line 'c1' pass of the compiler should come in at about 26 kb, versus 22 kb for the pdp-11 version. I'm also progressing on the minimal Xinu system, but I cannot claim that it works as yet.

To give you folks an idea of where it is at, I have made the development repo public, it can be found on:
http://1587660.websites.xs4all.nl/

If anybody wants to attempt a build of their own, I'm happy to give details.
 
Base Camp 1

Base Camp 1

There has been some good progress and I've reached "Base camp 1", so to spreak:
- The Ritchie C compiler has been ported, only floating point remains to be done. Structures, unions and bit fields are all supported, as are longs.
- There is a full unix assembler with e.g. support for local labels and synthetic jumps
- Other tool chain elements (ld, nm, strip, etc.) have been ported as well

The toolchain port has been guided and tested by a port of 1983 Xinu to Stuart's breadboard: that port is now largely done:
- The core (processes, semaphores, messages) has been fully ported
- The real time clock (using the 9995 timer) has been ported
- The IO api has been ported
- One device driver, the console terminal, has been ported
It is currently some 7.5KB in size, with a disk driver and file system it will probably end up at about 11KB.

All in all, it has been a productive 90 days, also considering that the TI-C compiler became available as another option in that time frame as well.

Now it is time to ponder where to go next and I'd like input. I have three topics on my mind:

1. Floating point

Operating system kernels normally don't need floating point, so I have no direct need to port this, but completing the compiler port is perhaps worthwhile in its own right. The pdp11 floating point instructions are rather different from those on the 99110 or the 990/12. I am tempted to emulate pdp11 style instructions and make the compiler porting work easier. Any alternative ideas? Any pointers to high speed floating routines for the 9995/99105?

2. Memory management

I'd like to extend the little breadboard with some memory management. I am torn between doing something very simple and replicating the Powertran design. From the schematics alone I am not entirely sure how the Powertran manages memory. Who can tell me how it was designed to work?

3. Disk

I'd like to extend the little breadboard with a disk. A very simple solution would be to use ram disk, but this requires the CPU to copy the data and I prefer something with dma. Another solution is to use a microcontroller with attached sd card to more or less emulate the Powertran setup with a 9911 and a 9909. I'm thinking something like this design:
http://www.nathandumont.com/node/204
https://github.com/hairymnstr/Z80-Project-Mark-2/tree/master/pic

Either I could use the PIC device of the above or a Propeller chip. The advantage of the former is that it is a 5V part and that the flash is on chip. The advantage of the latter is that it is easy to program and probably has more processing power, but it is a 3.3V part. The 5V/3.3V could be bridged with resistors. However, adding resisters is perhaps wise anyway, to limit current if the microcontroller accidently drives the lines at the same time as the CPU due to a microcontroller programming error.

Who has ideas for the simplest thing that could possibly work?

Paul
 
I'm happy to report that the compiler port has now sufficiently progressed that it can compile a 200 line C program correctly: printf is now working. The output code is about 1.3 kb, so using some very rough arithmetic the 4,000 line 'c1' pass of the compiler should come in at about 26 kb, versus 22 kb for the pdp-11 version. I'm also progressing on the minimal Xinu system, but I cannot claim that it works as yet.

To give you folks an idea of where it is at, I have made the development repo public, it can be found on:
http://1587660.websites.xs4all.nl/

If anybody wants to attempt a build of their own, I'm happy to give details.

Hi Paul,

I've been watching your progress and decided to dive in and try and do a build with the compiler so far. I didn't want to do a full Linux install so decided to try Cygwin, which seems OK for the task.


First of all, is there anyway to download in bulk? Clicking each file followed by the download button is reasonably time consuming to say the least.

I had to tweak the makefiles, but really only to do with DESTDIR and the 'install' options - no big deal. The makefile for c2 didn't work at all. I needed to change the build to $(CC) ${LDFLAGS} -o c2 c20.o c21.o. Again, no big deal.

I have now built cpp, c0, c1, c2 and as. crt is fine but it needs ld which I can't get to build. Looking at ld.c and nm.c they have what looks like 'local' includes for ar.h and a.out.h (i.e. they are in "" rather than <>). Any thoughts? Also, do I have to define __pdp11__ ?

Also, I'm pretty much guessing at the command line options for c0, c1 and c2. Here's what I do:

../bin99/cpp main.c main_cpp.c
../bin99/c0 main_cpp.c main_c0.1 main_c0.2
../bin99/c1 main_c0.1 main_c0.2 main_c1.s
../bin99/c2 main_c1.s main.s
../bin99/as -o main.o main.s

Great work though!

Dave.
 
Back
Top