Re: [TUHS] 2.11BSD on a Z180 (was: merry christmas)

Yes, OK, I see that there are unanticipated problems with the 2BSD Z180 port. Basically I had thought that the kernel ran like a userspace program, I knew there might be overlays involved with the code space, but I hadn't realized there are also overlays with the data space (from what you say I guess the mbufs are accessed using a kind of a "far" pointer). Anyway, I will check into it further. Based on the previous day's conversations I got inspired to continue the project, I got out the 2.11BSD toolchain which I had ported to a modern machine as a cross compiler (actually Mac OSX although I was using it like a poor man's Linux)... started again using Linux and a different way of building that would require less change to the Makefiles, fixed all compile warnings, fixed many bugs, it now produces: bin/ar bin/as bin/cc bin/ld bin/nm lib/c0 lib/c1 lib/c2 lib/cpp lib/crt0.o lib/libc.a lib/mcrt0.o usr/bin/lorder usr/bin/ranlib usr/lib/libc_p.a The executables above are x86-64 Linux ELF executables that work alike to the corresponding PDP-11 2.11BSD a.out executables, except that hard coded paths like /usr/include or /usr/lib have an extra prefix added to them, at the moment it works like this: /home/nick/src/2bsd_cc.git/bin/cc contains a hard coded executable path of /home/nick/2bsd_cc.git/lib.cpp /home/nick/src/2bsd_cc.git/lib/cpp contains a hard coded include path of /home/nick/src/2bsd_cc.git/usr/include and so on, these are set up at build time. Changes to the makefiles are pretty minimal, in the libc source directory I had to change things a bit to make it refer to the cross compiler rather than the native compiler, by changing stuff like "cc" to "${CC}" and adding stuff like: DESTDIR=../../.. CC=${DESTDIR}/bin/cc and so forth. The revised toolchain if compiled with -DPDP11 will be more-or-less as original, so it should not break the self-hosted compile system (up to possible minor breakage because I haven't tested this mode yet), for instance if the original code looked like this: int some_function(); ... some_function(a) int a; { some code } then it would now look like this: int some_function PARAMS((int a)); ... int some_function(a) int a; { some code } where the PARAMS macro is set up appropriately depending on whether we are compiling on the PDP-11 or the modern Linux machine. One significant difference with the cross toolchain is that I have translated the PDP-11 assembler /bin/as from assembler into C. So I guess it will be slightly slower and use slightly more memory, but I doubt the difference would be noticeable in practice. In future when I merge my changes into 2.11BSD and fix any breakage, I'll probably just delete the as0.s, as2.s and replace with as0.c, as2.c. Also I fixed some memory allocation bugs and illegal pointer dereferences in the other utilities that just happened to be benign on PDP-11. Anyway, I'm pretty stoked because after successfully building the C library, etc, with the cross toolchain, I compiled a hello world program and copied it into the running simh system, it executed without problems. When I compiled the same program on the self-hosted compile system in the running simh system everything was the same except the final executable, I will have to pay a bit of attention to the lorder and tsort stuff when it builds the C library, to make sure everything comes out in a predictable way for comparison. I will test this more extensively in the coming weeks, e.g. by building a kernel using the cross toolchain and checking it's the same. I am nearly ready to put the cross toolchain on bitbucket, but I just want to take a bit of care before doing "git commit" to make sure it's not capturing any junk I don't want in there, so I will do it later. I had better pay some attention to the family :) Happy new year everyone. cheers, Nick On Fri, Dec 30, 2016 at 5:20 AM, Ron Natalie <ron(a)ronnatalie.com> wrote: