🚀 go-pugleaf

In article <21361@weitek.WEITEK.COM>, weaver@weitek.WEITEK.COM writes:
> In summary, if you are writing an application from scratch, you
> can minimize this effect in an almost (but not quite!) machine
> independant way. So for new programs, I think natural alignment
> is a good time/speed tradeoff. I also think that supporting 
> unaligned data by both traps and special in-line code is a good
> idea, since so many programs have long histories. 

This statement may be true in general, but it is not always true.  For example,
I wrote a program tracing system that writes out a trace file consisting of a
mixture of bytes, halfwords, and full words.  It is crucial to this system
that the byte quantities only take up 8 bits (otherwise the size of the already
large files grow by a factor of 2 or more).  However, it means that I need
to do unaligned stores into the trace buffer.  And, since I trace programs in
real time, I need to do the stores fast.

The MIPS R2000 has a 2 instruction sequence that can store a half/fullword
quantity on any byte boundary.  On SPARC, it takes 7 instructions to store
fullwords byte-by-byte.  Comming from Berkeley, I hate to say it, but this
is another case in which MIPS has a much better designed machine than Sun (-:

/Jim