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,a1ce307c10055549
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 2002-12-18 14:05:12 PST
Path: 
 archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed-west.nntpserver.com!hub1.meganetnews.com!nntpserver.com!telocity-west!DIRECTV!sn-xit-03!sn-xit-01!sn-post-01!supernews.com!corp.supernews.com!not-for-mail
From: "Randy Brukardt" <randy@rrsoftware.com>
Newsgroups: comp.lang.ada
Subject: Re: calenday (was Re: IBM Acquires Rational Ada
Date: Wed, 18 Dec 2002 16:03:16 -0600
Organization: Posted via Supernews, http://www.supernews.com
Message-ID: <v01s8nckvfo099@corp.supernews.com>
References: <3DF1615C.7AAAC86E@adaworks.com>
 <at24vr$mf3$1@slb5.atl.mindspring.net>
 <8db3d6c8.0212091445.12594821@posting.google.com>
 <at4rfn$ju2$1@slb9.atl.mindspring.net> <3DF628C4.7090607@cogeco.ca>
 <a1sJ9.161$Z74.587@dfw-service2.ext.raytheon.com>
 <3DF6653D.3030603@cogeco.ca>
 <8db3d6c8.0212101850.51506572@posting.google.com>
 <at7fi7$7fc$1@slb0.atl.mindspring.net>
 <WcIJ9.2225$c6.2445@bos-service2.ext.raytheon.com>
 <ata1n7$g5g$1@slb4.atl.mindspring.net> <3DF8D33F.9020205@cogeco.ca>
 <atk8s0$7dm$1@news.uni <wcc4r9b40ka.fsf@shell01.TheWorld.com>
 <3E00C9AB.8040108@cogeco.ca>
X-Newsreader: Microsoft Outlook Express 4.72.3612.1700
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3719.2500
X-Complaints-To: abuse@supernews.com
Xref: archiver1.google.com comp.lang.ada:32059
Date: 2002-12-18T16:03:16-06:00
List-Id: <comp.lang.ada>

Warren W. Gay VE3WWG wrote in message <3E00C9AB.8040108@cogeco.ca>...
>Robert A Duff wrote:
>> "Marin David Condic" <mcondic.auntie.spam@acm.org> writes:
>...
>>>And I wouldn't really characterize the need as relating to "weird"
hardware.
>>>I've not usually found much problem, for example, getting a
rep-clause to
>>>work to line up with some register word or other device. Usually, its
a case
>>>of someone with a communication link packing things together as
tightly as
>>>possible or from hardware substantially different from the thing
doing the
>>>reading. You get odd-sized bit fields, things that span byte or word
or
>>>longword boundaries, unusual numeric formats (1750a 48-bit float, for
>>>example?) and things of that nature.
>>
>> That's the sort of thing I meant: you're interfacing to something
>> (hardware or software protocols) that is "weird" from the point of
view
>> of the computer hardware you're running on.  Sometimes the compiler
>> supports bit fields that are "natural" for *this* computer, but your
>> data is coming from a computer with a different word size, or
different
>> natural alignments, etc.
>
>Imagine trying to deal with 9-bit bytes as they had on the Honeywell
>Level 66 machines (36 bit words) ;-)  No 9 bit bytes ever
>made it to the Internet (due to its octet nature), but if you
>had to create a hardware interface to such a beast, you may be in
>a different situation ;-)


We had to write a cross-compiler to such a machine (the U2200). That was
interesting. :-) (Especially handling 36-bit constants on the 32-bit
machine.) It's one reason why I am not enthusastic about trying to set
strong rules for rep. clauses -- because they vary so much on different
hardware.

         Randy Brukardt.