pyramid architectural restraints

[bob at hhb.UUCP]

My company created and now sells the CADAT digital simulation system which
incorporates hierarchical concurrent fault simulation capabilities.
The software package represents at least 20 man years of effort and
is not trivial in any respect.

The problem is this:

	It was originally written in C and was first implemented for a
16 bit architecture.  Since we are dealing with such vast amounts
of information to describe the topology of a circuit, we went to
great pains to make our data-structures as lean as possible.
Of course this meant that many of our data structures were
`hand' built via pointer arithmetic and such. A typical example is
a data structure we use to describe one device in a circuit.
(i.e. and,nand,nor,jk-flop....)  It has a fixed header but the
data that follows it is variable in length, with its structure
being derivable from the information in the header.  If we went to
using C structures to define this information, the padding done
by the compiler would increase each device entries size by 25%.
There can be million of devices in a single circuit.

When we are simulating VLSI components, we often have 'device tables'
which have sizes of 2-3 meg.  This 25% increase in space could have a
serious impact on our performance if we then started being paged by
the system.  In digital simulation, performance is the name of the
game cause Test engineers just aren't cheap.

I know, memory is `cheap', but no matter how much memory i have, 
this simulation system will want to use it, and paying a 25%
penalty for `structured programming' is hard to stomach.

We were doing fine.....

The system now runs under 12 different version of UNIX on both
68000's and Vaxen.  It also runs under VMS.  We hit our first
snag on the Pyramid system we are evaluating.  It compiled
fine.. but you know the rest.....  We `core dumped' when we accessed
a long word on a non quad byte boundary.  We also found that Ridge will
exhibit the same behavior as the Pyramid. Along with the CCI Power 6/32.


We now have a dilemma.  Spend 10 man-months and rewrite the
data structures we have for these 3 machines and incur the 
25% memory penalty ?

Or just avoid architectures of this type ? 

How many architectures of the future will have this restraint ?
A machine we are looking at now for a CADAT implementation is
the ELEXSI.  It is a super-mini with IBM mainframe performance
but it offers Vaxen like addressing and won't pose any problem
to us.

What are the opinions in net-land.. Should we re-write or just
ignore the (few ?) machines with this restraint ?


======================================= Be