Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!dali.cs.montana.edu!uakari.primate.wisc.edu!sdd.hp.com!spool.mu.edu!uunet!kddlab!cs.titech!titccy.cc.titech!necom830!mohta
From: mohta@necom830.cc.titech.ac.jp (Masataka Ohta)
Newsgroups: comp.arch
Subject: Re: endian etc
Keywords: endianness??, cache
Message-ID: <181@titccy.cc.titech.ac.jp>
Date: 13 May 91 07:16:05 GMT
References: <2496@cybaswan.UUCP> <3407@spim.mips.COM>
Sender: news@titccy.cc.titech.ac.jp
Organization: Tokyo Institute of Technology
Lines: 32

In article <3407@spim.mips.COM> zalman@mips.com (Zalman Stern) writes:

>A real solution would be to add byte lane swapping hardware to the chip.
>This hardware would actually swap the bytes on every load and store
>depending on the byte order bit. (it can stay in the status register, it
>doesn't matter.) That way, memory is laid out so that bytes are always in
>the same place and word operations swap them around as necessary. If this
>were the case, buffers would not need to be byte swapped at all.
>
>So why don't we do this?

Surely, it is a real sulution to have a bi-endian OS. By doing so, external
bus (and OS and IO) can have some fixed endian which may or may not be
different from user processes.

But, with R3000, it is a bad idea to do so, because R3000 was designed
so that byte sex of the whole system (including bus) is changable. The
byte flipping of R3000 is done right.

R3000A, which allow dynamic changing of byte sex, should have designed
to allow byte sex flipping both of CPU and of bus independently.

>The word over here in software is that the
>hardware is expensive in terms of space and time. Its very likely to end up
>on the critical path for loads and stores.

I don't think so. A byte flipping multiplexer (for non-word access)
already exists on the path for loads and stores. So, it is only
necessary to add one more mode bit (to determin byte sex of bus) and
two more flipping patterns.

						Masataka Ohta