68020/68881? (also UIPC note)

[Alex S. Crain]

	About the UIPC code: the lastest version of the code is uipc-1.4.tar.Z,
not uipc-1.31.tar.Z as I said before, and its available from both umbc3 and
Brant's machine. umbc3 has all the various versions of the code available 
because its the only way that I have of keeping backups :-).

	The ftp sources are:
		umbc3.umbc.edu		[130.85.1.3]
		cis.ohio-state.edu	[128.146.8.62]

	Now, about this 68020 business:

In article <1989Oct29.214226.17546 at i88.isc.com> botton at i88.isc.com (Brian D. Botton) writes:

>1.	I have not verified this, but the exception stack is probably
>	different between an 010 and an 020.  It is different between
>	the 030, 010 and 000.  The kernel would have to know how to
>	deal with the slight differences.  I think this would be fairly
>	easy if you had source.
>
>2.	When there is a context switch you need to save the reigesters in
>	the 68881, unless you want to run under the assumptiont that only
>	one process can use the 68881 at a time, and that might not even
>	work correctly all the time.  Again, this would be easy to fix if
>	you had source.

	I haven't dug through /unix in awhile (July, actually) but I'm willing
to bet that I could fix both of these problems without source (Boy, do I feel
infallable today) and I would be willing to do it if someone designed a 
board. The last two projects that I was working on when my disk blew were
a replacement tty000 driver and symbolic links. I had the latter working
and was settling the implimentation details when the machine died, the former
was only in the design stages. The kernel was compiled with minimal 
optimization, (or else the compiler is very stupid, quite likely), and I've
figured out how to do runtime modiications of the text area, so having
device drivers that do kernel overlays is pretty straight forward. The symlink
code did just that, with driver init() function replacing the header of
nami() with a jump instruction. Works like a charm. 

>				  The C compiler does have options for a 68881.
>When I tried it I got a message saying I needed the 020 binary for ccom.  Does
>this mean the FPA was on the verg of release or just that the compiler is
>universial in nature?

	The compiler driver program (/bin/cc) knows about alternate compilers,
but the only compiler supplied is teh 68010/nofpa version. If yu try to
compile for 68020 or 68881, cc will die with errors. Gcc, however, can be
built to da anything.

	My vote is for an fpa device, useable by one process. It would make
things more portable, and we could write a /dev/fpa driver in software for
machines without the upgrade.


-- 
#################################		:alex.
#Disclamer: Anyone who agrees   #    University of Maryland Baltimore County
#with me deserves what they get.#	alex at umbc3.umbc.edu
#################################