On Wed, 8 Jul 1998, matthew green wrote:

> hi chris.
> 
> 
> this reminds me of the work i started on ~18 months ago, that kept
> everything in sys/arch/sparc.  i punted when i got stuck on the
> new register window traps and how to deal with the different trap
> frames (and how userland deals with it also).
> 
> i think there is more than just the devices that can be merged,
> but not sure about the best way to do it..

Header files should not be that difficult, but adding another set of
#ifdefs to deal w/different page sizes make my stomach turn.

Forget locore.s.  80% code divergence and a bevy of new instructions that 
the old assembler won't grok.  pmap.c is even worse. The sparc64 firmware
interface shares more with ARM and PPC than with sparc.  Same with the
bootloader.  

So what's left?  Parts of trap.c have not diverged much, and the fpu emul
code is mostly unchanged.

The question is whether merging this stuff makes things better or worse.
In addition to the not insignificant amount of work involved in merging
the two source bases, will we be in constant fear that a bug-fix for
sparc64 will break sparc or vice-versa?

=========================================================================
Eduardo Horvath				eeh@one-o.com
	"I need to find a pithy new quote." -- me