Re: RISC

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

"Robert A Duff" <bobduff@world.std.com> wrote in message
news:wccofv1r65n.fsf@world.std.com...
> Ada 83 said that compilers don't have to support rep clauses that can't
> be "handled simply by the underlying hardware".  It's not entirely clear
> what that means.
>
> Ada 95 has a whole lot of verbiage that amounts to more or less the same
> thing: the compiler has to support some minimal capabilities that we
> thought were "simple" or "reasonably efficient" on all machines.
>
What it means is that the compiler is free to say "Sexual Penetration Upon
You!" whenever it feels like it. :-) An interesting clause I'd like to write
into the contracts *I* have to live by! :-)

I can live with most of Ada's representation limitations and most of the
time don't really care. There just needs to be *some* mechanism for me to
say "On the machine I'm targeting, the following layout of bits makes
sense - so just do what I tell you to do..."

I could deal with restrictions on such represented objects *after* I get the
layout I asked for, provided that at minimum, I can assign to/from the
object and its sub-fields. (Records or arrays are where I care about this.
Most other things just don't matter that much or the compilers that are out
there don't seem to puke on the representations as long as they aren't
contradictory.).

> If I were designing a language from scratch, I think I would require
> much more, including bit fields oddly aligned, and crossing word
> boundaries and so forth.
>
Yea Verily And For Sooth! So long as we are going to have to deal with
hardware designed by hardware engineers (instead of compiler writers) or
communicate with data streams that come from places not programmed in Ada,
*someone* is going to create data that needs really bizarre representations.
Ada needs to be able to connect to that data - and most of the time it does.

> I don't think the "underlying hardware" is really the issue, especially
> in this networked era, the piece of hardware you're trying to mimic
> might be a different computer, or some weird peripheral device.
>
From a practical perspective, I don't think it is that much of an issue. In
theory, someone might one day (again) make a machine that deals with sixbit
data. What is the likelihood there will be a huge demand for Ada compilers
for such a machine? Most machines these days are byte oriented. You've got
to deal with byte sex, but beyond that you can pretty much count on hardware
having some sort of support for byte sized data. It shouldn't be that tough
to map most rep clauses onto that sort of machine.

> Tucker's right: these things are hard to implement efficiently.  But I
> think it's worth it.  I really think the usefulness of Ada's rep clauses
> is seriously damaged by their lack of portability.  If I ran the circus,
> all compilers would support exactly the same record layouts.
>
I'll accept the efficiency argument and offer to give up some usages of the
data if that helps. Maybe Ada was overly-ambitious in this area and creating
some alternative mechanisms that don't have to satisfy all the possible
demands might make life easier.


> There are also a lot of things that rep clauses just can't express.  Eg,
> TCP/IP protocols often have data structures defined like "a count byte,
> followed by an array of sub-records" where the count gives the number of
> sub-records, or the number of bytes including (or not including) the
> count byte itself.  I would like to have a language that could describe
> that sort of thing at a reasonably high level.
>
Yes - this would be *very* nice! There are often in data streams things of
uncertain quantity which become very hard to represent in the usual Ada
structures. You get things like "This16 bit word will tell you how many
doohickies will follow...." and it will be surrounded by fixed data. It
doesn't map well to records - but maybe some other structure could be
created to handle it. Typically, you'll end up "rolling-your-own" by
building some kind of dynamic data structure to hold these things. You
construct the data structure as you read the data in. Not that hard to do,
but it would be *really* nice to describe one of these things at a high
level and just have all that done for you by the compiler.

There would be representation issues here as well, but I think that if the
operations on the structure are limited to assignments, it may not be that
hard to handle. I'm not at all sure what sort of language features would be
needed to support this. I'd be interested in hearing any ideas you had on
it.

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/