From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,78b2880bc7e78e39
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 2001-03-19 09:52:13 PST
Newsgroups: comp.lang.ada
Path: 
 supernews.google.com!sn-xit-03!supernews.com!news-out.usenetserver.com!news-out-sjo.usenetserver.com!europa.netcrusader.net!152.163.239.130!portc01.blue.aol.com!uunet!dca.uu.net!ash.uu.net!world!bobduff
From: Robert A Duff <bobduff@world.std.com>
Subject: Re: RISC
Sender: bobduff@world.std.com (Robert A Duff)
Message-ID: <wcc3dc93ayq.fsf@world.std.com>
Date: Mon, 19 Mar 2001 17:49:49 GMT
References: 
 <JqQr6.1962$y47.389981@news2-win.server.ntlworld.com><NH2s6.4048$y47.865896@news2-win.server.ntlworld.com><Zv4s6.3640$54.4417@www.newsranger.com><wccpufjaxz5.fsf@world.std.com><98qumf$5sf$1@nh.pace.co.uk>
	<wccbsr23n0q.fsf@world.std.com><98r4g1$7r1$1@nh.pace.co.uk>
	<3AB22CB2.E8A851A5@averstar.com><98tmai$5q5$1@nh.pace.co.uk>
	<wccbsr1qw7b.fsf@world.std.com> <995cfh$mm9$1@nh.pace.co.uk>
Organization: The World Public Access UNIX, Brookline, MA
X-Newsreader: Gnus v5.3/Emacs 19.34
Xref: supernews.google.com comp.lang.ada:5861
Date: 2001-03-19T17:49:49+00:00
List-Id: <comp.lang.ada>

"Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> writes:

> 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 

... and slices

>...can cause all sorts of problems for
> efficient compilation. Hence my notion of restricting usage isn't really
> going to help.

> 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 ...

Yes, you're willing to live with inefficient code in *those* cases, and
you have no choice -- those cases are inherently inefficient.  But I'll
bet you're *not* willing to live with inefficiency for loading a 32-bit,
properly aligned integer.  So the compiler has to treat that as a
special case (ie, generate different code for these two scenarios).

- Bob