🚀 go-pugleaf

> 
>>>
>>>> ...the unaligned-access trap facility exists in order to provide some
>>>> level of support for "old" databases.  That is, lots of machines allow
>>>> access to any size of data on any boundary (unaligned 32-bit words,
>>>> unaligned 16-bit halfwords).  There must (we guess) be many databases
>>>> out there that were created under the assumption that such access will
>>>> always be possible...
>>>
>>>     1) Do such databases *really* exist?
> 
> Er, well, I have no proof, but gosh, we just took it on faith....  We should
> probably punish ourselves.
> 


Such databases do exist.  Specifically, HHB Softron has/had a CAE package
called CADAT which required 32 bit loads/stores from arbitrary 16 bit
alignment.


>>>     2) Are they difficult to convert?
> 
> This is a good question.  With proper documentation, the conversion job
> might be easy and quite perferrable to "support" of the old format.
> 


When Ridge Computers (my previous employer) tried to port CADAT to the
Ridge architecture, which requires 16 bit alignment for 16 bit loads/stores,
32 bit alignment for 32 bit loads/stores, and 64 bit alignment for 64 bit
load/stores, they failed due to these alignment problems.  When Pyramid
Technology tried to port CADAT to their architecture they also failed due
to alignment problems.  Pyramid actually provided HHB Softron with a special
version of their microcode which allowed non-aligned accesses.  Last I heard
HHB was still running with this "non-standard" Pyramid microcode.


>>>     3) Will they perform acceptably with all that trap overhead?
>>>

Depends on your definition of acceptable.  In the case of CADAT on a
Ridge we decided the performance degradation wasn't worth the effort
to provide for non-aligned accesses.


>>>     4) Would it be easier to get the compiler to generate 
>>>        whatever sequence of instructions would be required to
>>>        access unaligned operands without a trap?
> 
> The compiler (often/always) can't know the alignment of operands.  Thus,
> it would have to generate slow code for all accesses.  The trap mechanism
> lets at least 32-bit-aligned-32-bit accesses run at full speed.
> 

Correct.


>>>     5) Did the idiots who designed such non-portable databases
>>>        make other mistakes that will kill you anyway? (Byte order,
>>>        anyone?)
> 

The people at HHB weren't idiots.  They were programmers constrained
by small address space machines who did what they could to provide
some useful functionality.  Would you rather they have postponed 
development of their product until they had an architecture that
supported a decent sized address space?  Or would you suggest they
had spent more money for a machine with a larger address space?
Sometimes the real world throws constraints at you that you can't
ignore.

Ken Klingman
Dana Computer
hplabs!dana!kck