[TUHS] Introduction

Jose R. Valverde jrvalverde at cnb.csic.es
Wed Jun 4 21:57:29 AEST 2008

Dear Oliver

	Astounding work!

What reference source are you using for the reconstruction process?
I bet you are having a look at the source code for Plexis sys3 in the 
TUHS archives, and comparing with the stock sysIII from SCO, right?

FWIW from the source trees from SCO and Plexis, the code layout was
arranged by CPU. I'd bet the WEGA authors had access so SysIII sources,
and if they'd gone through the pains to get it, then they might as
well got both -or perhaps Plexis, which should have been more easy
to get- to use as their codebase. So a comparison of both source 
trees should yield useful insights from the differences between PDP11,
VAX and Z8000.

BTW, as I remember practice in the '80s it was not uncommon to write 
source in C and then tweak the assembler produced by hand to gain some
extra efficiency or fixes. It is also possible that the authors resorted 
to tricks (like casting an int parameter to char) to force the compiler 
generate the code they wanted. You should also watch out for external or
global symbols. It is also possible that the system was compiled with a 
different (may  be earlier) version of the compiler that was later shipped. 
If you can't get stock code to render the same asm then I'd bet for the 
latest explanation (different compiler versions).

Other than that, you are doing an astounding work!

BTW, there are other Z8000 UNIX floating around. Maybe one of them will
shed some extra light.

> So my goal is now to get the kernel sources right now to make the
> neccessary changes to get TCP/IP running in the kernel. As you might
> think now this is not so easy as it sounds. The sources for some objects
> of the kernel survied over the time, but many are missing. I'm now
> sitting here since a month disassembling the original kernel object and
> writing the disassembled code back in C. I've started this by having lets
> say nearly-to-zero ASM knowldege and I'm making good progress. Not much
> is left, but from time to time the C files are not compiling to
> exactly the same object which is in the kernel. Some times other
> temporary registers are used for operations, or I can't get to the same C
> code doesn't matter of what I'm trying and so on. I'm trying to get 100%
> the same object to be 100% sure I have the same code the object was built
> with. The compiler on that system should be the same but of course I
> can't guarantee that for sure.


	These opinions are mine and only mine. Hey man, I saw them first!

			    José R. Valverde

	De nada sirve la Inteligencia Artificial cuando falta la Natural

More information about the TUHS mailing list