> Hiya,
> 
> Is there any chance to make the tools used to compile NetBSD for the
> pdp10 available for download?  I'd be interesting to see how it works so
> far (and to see if I can help, of course ;-).
> 
Hi!

There are no problem making the tools available, in fact, I just did :-)

I have put the files:

as-030919.tar.gz
cc-030919.tar.gz
ld-030919.tar.gz
objdump-030919.tar.gz
od-030919.tar.gz

as is the assembler, which have a syntax much like a subset of MACRO
but with some significant differences:

- Register numbers are prefixed with % and have octal naming. Hence,
  the registers are %0-%17.  All other numbers are in decimal if not
  prefixed by 0 in which case they become octal (as in C).
- The size of a constant (18 or 36 bits) is determined by its context,
  writing constants like 365000,,000000 are not legal. Write it
  0365000000000 instead. 
- Constants in code must have .long in front of it.
- Brackets are ok to use, and the contents will be parsed "recursively".
  Examples:
	move %1,[ .long 0365000000000 ]
	move %1,[ tlo %3,0123456 ]
- No macros like TXO or so exists, but the assembler files can be 
  preprocessed by cpp. Normal arithmetic works.

The assembler output is in "ELF36" format, which is similar to but not
identical to the normal ELF32 format with 9-bit bytes.  The output is 
relocatable and must be passed on to ld.

ld is the linker.  It takes files in ELF36 and produces either an ELF
executable or an executable in EXE format; the latter because it can
be loaded directly by KLH10.

cc is only the frontend that calls cpp, ccom, as and ld in order.
I have not put up the C compiler (ccom) for download; I am in the middle
of some heavy changes to it right now so I will make it available later.

od is an od but for 9-bit byte files.

objdump can disassemble, show the namelist and relocation info in a file.
It's a subset of its GNU counterpart.


There are two things that must be completed before any further pdp10 
development can be done.  One is to teach the linker about the ELF
link-set stuff; it's used in the kernel. Compiling a kernel otherwise
will bail out early.

The other thing is to finish my ccom code generator rewriting; to better
match instructions.  This will reduce the size of the kernel significantly
which is important; I want to keep all text and preallocated data in one
section (but later allocated data can be in any section) and the tools
are designed around this goal.

-- Ragge