riscy
[Top] [All Lists]

Re: MIPS R3000 - 2nd update

To: riscy@pyramid.com, jeremy@sour.sw.oz.au (Jeremy Fitzhardinge)
Subject: Re: MIPS R3000 - 2nd update
From: Drew Eckhardt <drew@nag.cs.Colorado.EDU>
Date: Wed, 23 Jun 1993 05:26:50 -0600
In-reply-to: Your message of "Wed, 23 Jun 1993 19:17:43 MDT." <199306230917.AA05932@sour.sw.oz.au>
--------

    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.

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.
    
    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

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.

    > *  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.


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.

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

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.

--------


 

<Prev in Thread] Current Thread [Next in Thread>