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,29f36805b9a20fe8
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 2001-04-03 03:02:29 PST
Path: 
 supernews.google.com!sn-xit-02!supernews.com!news.gv.tsc.tdk.com!falcon.america.net!sunqbc.risq.qc.ca!newsfeeds.belnet.be!news.belnet.be!uni-erlangen.de!news-nue1.dfn.de!news-han1.dfn.de!news.fh-hannover.de!news.cid.net!news.enyo.de!news1.enyo.de!not-for-mail
From: Florian Weimer <fw@deneb.enyo.de>
Newsgroups: comp.lang.ada
Subject: Re: Streams in Ada
Date: 03 Apr 2001 12:02:04 +0200
Organization: Enyo's not your organization
Message-ID: <87k852pahv.fsf@deneb.enyo.de>
References: <v7mx6.7111$MZ2.1190619@news2-win.server.ntlworld.com>
 <wccwv95fulm.fsf@world.std.com> <iq%x6.234$UK4.22262@www.newsranger.com>
 <tglmpjxutl.fsf@mercury.rus.uni-stuttgart.de> <9aa3dd$efb$1@nh.pace.co.uk>
 <tgofufwd4x.fsf@mercury.rus.uni-stuttgart.de>
 <zc1y6.352$UK4.34815@www.newsranger.com>
 <tgpuevurlk.fsf@mercury.rus.uni-stuttgart.de> <wccae5zw4hm.fsf@world.std.com>
 <878zlj6m41.fsf@deneb.enyo.de> <wcc7l13vvx7.fsf@world.std.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Xref: supernews.google.com comp.lang.ada:6393
Date: 2001-04-03T12:02:04+02:00
List-Id: <comp.lang.ada>

Robert A Duff <bobduff@world.std.com> writes:

> >...  There are quite a few Ada compilers out there which use
> > Storage_Element'Size = 8 even though it's inefficient on that
> > particular platform.
> 
> Which machines?  I've never heard of such a thing.

IIRC, in the AI dealing with 13.13.2(17), some vendor(s) claimed that
the current IA is inappropriate because it results in inefficient code
if a character is written to a stream because it has to be represented
in 8 bits.

With Storage_Element'Size, this isn't such a big concern, I think,
because usually, you can add all kinds of padding to make the
in-memory representation efficient.

> > An 8 bit char on a PDP-10 doesn't work.  Only values which are
> > divisors of 36 are acceptable.
> 
> I don't see why.  The PDP-10 hardware can deal with 8-bit bytes just
> fine (although you waste approx 1/9 of the bits).  Is there some
> subtlety of C I'm missing?

In C, each object must be representable as a sequence of bytes (i.e.
char values).  If you use 8-bit chars, words can only consist of 32
bits, not 36 bits.  So you have to run the PDP-10 in some kind of
32-bit mode.  As a result, you probably can't write system code in C.