Subject: MIPS R3000 - 2nd update

From: [email-masked] (Jeremy Fitzhardinge)
Date: Wed, 23 Jun 1993 19:17:43 +1000

Neil Russell says on comp.os.linux:
> *  I have decided that the IDT 79R3051E (the non FPU version) should be
>    used.  Since getting good pricing is hard unless quantities are high
>    I wish to stick to one type of CPU.  The board will be able to
>    accommodate the IDT 79R3081E (with the FPU and more cache) if the
>    user wishes to replace the CPU.  This would mean that full floating
>    point support routines need to be written; ho-hum.

I suspect the existing FPU emulator can form the core of a IEEE
FPU emulator.  The hard part would be replacing the 387 front end
with a mips one, assuming that the mips compiler uses a similar
subset of IEEE FPU as the 386 one.  Since they are both gcc, this
is probably the case.  Another guess: Mips FPU instructions are
not going to be as hard to interpret as 387 ones.

> *  The R3000 is able to be a little endian or a big endian machine.
>    Most operating systems that I've seen use the big endian mode, but
>    since linux runs on the 386, little endian may be more appropriate.

I don't know if it will make that much difference, but I suppose
little-endian is easiest.  Big endian will probably make talking to
ISA IO boards quite tricky.

What's your current thoughts on on-board IO?

	J

---

From: Drew Eckhardt <[email-masked]>
Date: Wed, 23 Jun 1993 05:26:50 -0600

--------

    >    point support routines need to be written; ho-hum.

IEEE floating point isn't *that* bad, I implemented normalization, addition,
and subtraction inside of 45 minutes for an assembler programming class, 
fast multiply and divide algorithms are well documented, and we allready
have 386 assembler source for a lot of things and 'C' source for the 
transcendental functions.
    
    with a mips one

Instruction decoding is trivial, it's just a matter of looking at 
the right bit fields.  The "hard part" will be translating the i386 
assembler routines for rounding, division, addition, multiplication, 
normalization, etc.

I guess this brings up an important issue : 

Software for the board, most noteably an X server and device 
drivers.  If it doesn't run Linux and X, it's an expensive paper 
weight.

We need to set some finite time deadline for the board component
specs (ie what chips, etc) so us software hackers can get started 
writing SCSI drivers, VM code, etc that our code will be done and
ready for debugging once the hardware is ready.

Since this is a hardware project, we're free to wire 
up the ISA bus so bytes on 16 bit transfers are automagically rearanged,
and as long as you don't splat a short to an 8 bit address or an int
to an 8 or 16 bit address and expect the bytes to come out in a given 
order, there aren't any problems.

IMHO, software compatability should be a more important issue, ie 
with commercial shrink wrap.  If people want to consider Ultrix 
binary compatability, little endian SPIM is the only way to go. 
If there's a SYSV MIPS ABI, we should comply with the endianness
of that.

I wouldn't be at all interested in a board that bore the burden
of abysmal ISA video performance, since I want a *useable* 
system that's more than a number cruncher.

A lot of cheap boards are avaible for ISA - ROM burners, 
internal modems, etc.  However, the question becomes : is it cheaper 
to buy Unix-capable (ie 16550 equipped serial boards) hardware on
the ISA bus where it's practical (ie, no video, SCSI, network),
or on the mainboard?

I priced serial boards with 16550AFN UARTs preinstalled, and came up
with $60-$80 for a four port board.  For a reasonable, non-busmastering
SCSI you're looking at $80 when reasonable SCSI chips that will interface
to the native DMA controller start at $5...

Serial : 

1.  2 and 4 port versions of the National Semiconductor 16550AF 
	are available from various sources (My NS databook only 
	shows the two port version, but its dated 1990), come
	in PLCC packages so they take a minimal amount of realestate,
	and the sockets are available in "normal" (ie, through
	the board and not surface mount) connectors (the 
	16550AFV on my modem is mounted like this).

2.  The 16550 has DMA interfacing signals on board, perhaps
	with modems like the World Blazer having > 20K bps raw data 
	rates and > 70K after compression, it might be a good 
	idea to take advantage of this.

3.  What *other* uarts are out there?  In microlab, we used 
	a nice DUART (same vintage as the 8250's) that was 
	buffered.

Ethernet : 

I don't know about the lance chip - using FTP, with 
LANCE equipped Decstations I can't seem to get over 
450K/sec sustained, good reason to use something else.

My old LANCE equipped HP's show similar throughput.

The HP Snakes use an Intel 82596, IBM RS6000's an Intel 82586,
and these things blaze (as in I can sustain close to 1000K/sec).

I don't have access to any reasonable NS 8390 equipped hardware,
does anyone know what these chips will do?

Something else to consider : if there were expansion slots
in these boxes (ie, there was also a native bus available) 
they might make reasonable gateway machines that didn't 
cost a whole lot of money.

Many vendors consider card slots a *server* only option.  This 
makes building gateway machines, etc somewhat expensive.  
If we have non-ISA slots (not necessarily CPU "local" bus slots, 
maybe something that works at wire-wrap compatable speeds (how 
fast *can* you go with wirewrap?)) to plug in peripherials in like a 
second ethernet port board, etc these boards would make great 
gateways.

SCSI :

What about the NCR53c700 series of chips?  FAST-SCSI,
inteligent controller using "scripts", blazingly fast.

Video :

What are S3 chips running cost wise, are they available in a PGA rather
than surface mount package, and what sort of glue would we 
need to make one work?  Opaque moves are tolerable with the 
S3, 24 bit graphics are possible, it will work at the resolutions
we want, and we could easily springboard off the work done on XS3.

--------

---

From: [email-masked] (Neil Russell)
Date: Wed, 23 Jun 93 14:34:41 PDT

> not going to be as hard to interpret as 387 ones.

FPU code is not that hard to write; I've done it before.  There seems to
be a fairly large amount of people wanting the FPU though.  That decision
doesn't need to be made until we do purchasing.

> ISA IO boards quite tricky.

I don't like the idea of hardware swapping the bits, so this favours
little endian, however, RISCos is big endian and has a few ISA bus
slots; so the software must swap the bytes itself; Mmmm, this is the
RISC way, after all...

-- 
Neil Russell		(The wizard from OZ)
Pyramid Technology			Email:  [email-masked]
3860 N. First Street			Voice:  (408) 428-7302
San Jose, CA 95134-1702			  FAX:  (408) 428-8845

---

From: [email-masked] (Neil Russell)
Date: Wed, 23 Jun 93 14:50:34 PDT

> ready for debugging once the hardware is ready.

That is kind of difficult right now.  We still have no-one interested in
doing one of the harder tasks on the board, notable the ISA interface.
Once there are people allocated to all the tasks, the design shouldn't
take long.  I figure we a looking at about October for the first
batch of boards.

> order, there aren't any problems.

I'm not in favour of doing this kind of byte swapping.  If this issue
really matters, then we should definately run the OS in little
endian mode.  If the OS must run in big endian mode then the software
would have to byte swap for 16 bit accesses; this is the RISC way after
all...  BTW, to stop any possible mis-interpretations before they
start, the CPU must be placed in either big or little endian mode
when its reset.  It cannot be changed later.

> If there's a SYSV MIPS ABI, we should comply with the endianness

Agreed.

> system that's more than a number cruncher.

Video, SCSI and ethernet are things that I'm not going to give up
on easily.