Re: RISC

["Marin David Condic" <marin.condic.auntie.spam@pacemicro.com>]

Werll, not being a compiler kind of guy, I don't really know what the
problems are. I think I understand what you're getting at - that the reading
and writing of individual fields can cause all sorts of problems for
efficient compilation. Hence my notion of restricting usage isn't really
going to help.

I suppose it is worth pointing out that in the *bulk* of the cases, a rep
clause isn't going to ask for things that are going to be hard or
inefficient. You use the rep clause to give yourself a nice, warm, fuzzy
feeling that somehow that 32 bit, longword aligned integer is going to
*always* fall in this position within the record so you're not scared that a
new compiler version is going to go move it on you and your I/O with some
other device is now screwed up. (I've had *SERIOUS* troubles with compilers
when asking for very simple things, like putting various record fields on 16
bit boundaries for a machine that supports 16 bit data. But Noooooooo! Data
had to fall on 32 bit boundaries or the compiler puked.)

In the cases where we have to deal with the perversities of some hardware
engineer who never worked on a compiler or had to build software to deal
with his strange representation of data, I guess I'd be willing to live with
inefficient code so long as I had some means of plugging in the data in and
impacting the device properly. If someone stuck an odd sized integer(1) into
some location that spanned longword boundaries and I've somehow got to plug
a number in there, I'd rather have an inefficient way of doing it than
getting told by the compiler that it won't do that at all because it is a
dumb idea - or simply get confused and think I was asking for a
representation that can't be done.

(1) I once had a serious disput with a casino roulette wheel operator over
what I considered to be an "odd" number. :-)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/



"Robert A Duff" <bobduff@world.std.com> wrote in message
news:wccbsr1qw7b.fsf@world.std.com...
> The complexity that Tucker was talking about is in generating code for
> reading and writing components.  If you want any reasonable kind of
> efficiency, and you insist on generality, the compiler needs to know
> several ways of accessing components: those that are nicely aligned on
> storage unit boundaries, those that are bit fields within a single word,
> those that are bit fields crossing word boundaries, those that are bit
> fields that are bigger than a word, &c.  And it's machine dependent
> (some machines have double-word shifts and whatnot), which means the
> complexity is multiplied across all targets supported.
>