Re: RISC

["Randy Brukardt" <randy@rrsoftware.com>]

Robert A Duff wrote in message ...
>"Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> writes:
>
>> And the only allowed operations on a table are assignments to/from
fields or
>> assignments to/from the whole structure. (No math or other stuff -
just data
>> motion) Would something like this take the burden off of the compiler
>> writer?
>
>I don't think it helps much.  If you do X.Y * A.B, the compiler needs
to
>extract bit fields for Y and B into registers.  Once they're in
>registers, doing the multiply is no problem.  Disallowing that multiply
>would not simplify.


For records, I agree, it doesn't matter much. For arrays, it certainly
would be a lot easier if you didn't have to deal with slices and
relationals on arrays of discretes. Those (and generic formal types) are
the reason that Janus/Ada doesn't support 'Component_Size very well.
I've never been able to figure out any sane way to implement an
arbitrary slice of a packed boolean array assigned into another packed
boolean array. Any particular case isn't too hard, but the general case
looks like:
          Bar (Start .. End) := Foo (Start+Offset .. End+Offset);
About the only thing I can see to do is punt and do it a component at a
time; but the performance would be abismal.

Still, Bob is right that "helpful" restrictions often turn out to be not
helpful. The obvious example is the restrictions on "others" clauses in
aggregates in Ada 83. We spent more effort trying to implement the
restrictions than we did implementing the aggregates in the first place
(I mistakenly implemented nearly full support for arbitrary "others"
clauses before discovering that it wasn't required or allowed.)

                    Randy.