S-expression I/O in Ada
in [ADA]
|
Prev: GPRbuild compatibility
Next: Irony?
From: Randy Brukardt on 10 Aug 2010 17:36 "Jeffrey Carter" <spam.jrcarter.not(a)spam.not.acm.org> wrote in message news:i3q8av$2o94$1(a)adenine.netfront.net... > On 08/09/2010 05:51 PM, Randy Brukardt wrote: >> >> Not sure if it still exists in the real world, but the compiler we did >> for >> the Unisys mainframes used Stream_Element'Size = 9. (The Unisys >> mainframes >> are 36-bit machines.) Stream_Element'Size = 8 would have made the code >> for >> handling arrays awful. > > What was Storage_Unit? 36? It was originally 36-bits (and really ought to have been 36), but that caused our front end to make strings with 36-bit characters. So ultimately, we changed it to 9-bits, and put strong alignment requirements on 18-bit and 36-bit integers. That fit better with the existing compiler implementation. (The change took more than 6-months of work, however, and really delayed the completion of the compiler, probably a contributing factor to none of the intended customers ever buying it.) Randy.
From: Randy Brukardt on 10 Aug 2010 17:42 "Dmitry A. Kazakov" <mailbox(a)dmitry-kazakov.de> wrote in message news:1o6jah15584x1$.1arrrgog9jdk7.dlg(a)40tude.net... > On Mon, 9 Aug 2010 20:17:40 -0500, Randy Brukardt wrote: > >> "Dmitry A. Kazakov" <mailbox(a)dmitry-kazakov.de> wrote in message >> news:1y1c8zzqmcer5.po56hkesa968.dlg(a)40tude.net... >> ... >>>> For these, you don't want modular semantics -- you just want >>>> a data type whose representation matches what you're >>>> interfacing/communicating with, such as "type Octet is >>>> range 0..2**8-1;" >>> >>> The problem is that these things require both array-of-Boolean view and >>> arithmetic. I agree that when arithmetic is used, then it has to be >>> wide. >>> E.g. when interpreting sequences of octets as little/big endian numbers, >>> we >>> never use modular arithmetic. But integer arithmetic is incompatible >>> with >>> array/set view. >> >> What have you done with Dmitry?? You can't be the *real* Dmitry! :-) > > Brainwashed me? (:-)) > >> Array-of-bytes views and arithmetic views are of clearly different types, >> with different sets of operations. These shouldn't be mixed, logically or >> any other way. If you need to go between these views, you need some sort >> of >> type conversion (or Unchecked_Conversion or Stream'Read or...). Thus, it >> is >> *never* necessary to do operations on both views at once, and it is >> irrelevant what the "math" operations for octets is. If Ada gets anything >> wrong about this, it is that it has math operations at all for >> stream_elements. > > Right, but there is no contradiction because it is more than one type > involved. What I meant is: > > type Octet is ...; > > -- Array interface to access bits of the octet (not Ada) > type Bit_Index is range 1..8; > function "()" (Unit : Octet; Bit : Bit_Index) return Boolean; > procedure "()" (Unit : in out Octet; Bit : Bit_Index; Value : Boolean); > > -- Arithmetic interface, immediately leads out of octets (not Ada) > function "+" (Left, Right : Octet) return Universal_Integer; > function "-" (Left, Right : Octet) return Universal_Integer; > ... > So when you write: > > Little_Endian_Value := Octet_1 + Octet_2 * 256; > > There result is not an octet, as it would be with a modular type. > Presently > it is just broken. I wouldn't mess with mixed "+" routines that return other types. I'd just convert the Octets to a suitable type and add them. That is, any mess should be in type conversions, not in operators. Since we're inventing things, I would suggest: -- Conversion function (Not Ada): function "#" (Right : Octet) return Universal_Integer; Little_Endian_Value := #Octet_1 + #Octet_2 * 256; And now you don't need any Octet math. BTW, the "#" operator was suggested by Jean Ichbiah and others back during the design of Ada 83, to be used for conversions between types. It's a pity that it or something like it never made it into Ada. (It comes up each time and still is rejected.) Randy.
From: Randy Brukardt on 10 Aug 2010 17:56 "Natacha Kerensikova" <lithiumcat(a)gmail.com> wrote in message news:9db37b80-acbb-4c9f-a646-34f108f52985(a)v15g2000yqe.googlegroups.com... .... >Now I can't explain why your posts [referring to Dmitry here - RLB] >often make me feel Ada is >completely out of my tastes in programming languages, while other >people's posts often make me feel Ada is probably an improvement over >C in term of personal preferences. However I have the feeling I got >much more personal improvement from your posts (improvement still >meaningful even if I eventually drop Ada to come back to C), and I'm >grateful for that. I suspect this is because Dmitry's worldview is ummm, unusual, for the lack of a better word. I suspect some of what he is describing is more confusing than helpful to a newcomer. As someone else pointed out, there are about as many worldviews as there are programmers. This newsgroup has a very diverse set of worldviews, and you will find that there rarely is agreement about anything much more complicated than the proper way to write "Ada". So it is important that you find a style that works for you, and don't read too much into anyone else's style. OTOH, you'll also get suggestions on improving your style that most of us would agree with. *Everyone* can improve their style and learn something from others... Randy.
From: Randy Brukardt on 10 Aug 2010 18:06 "Robert A Duff" <bobduff(a)shell01.TheWorld.com> wrote in message news:wccy6ceaaxz.fsf(a)shell01.TheWorld.com... > "Randy Brukardt" <randy(a)rrsoftware.com> writes: > >> Not sure if it still exists in the real world, but the compiler we did >> for >> the Unisys mainframes used Stream_Element'Size = 9. > > Interesting. Can these machines communicate with non-Unisys machines > over a regular TCP/IP network? E.g. send an e-mail using standard > protocols, that can be read on a x86? > > I assume Storage_Element'Size = 9, too. Correct? I think so, although we had tried for a while to use 36 for such things (it was a word-addressable machine). But since we were using the C code generator, it emulated a 9-bit byte addressable machine for the obvious reasons, and eventually we changed to that model, using strong alignments to make the code more efficient. > Next question: Is (was) there any Ada implementation where > Stream_Element'Size /= Storage_Element'Size? > >>...(The Unisys mainframes >> are 36-bit machines.) Stream_Element'Size = 8 would have made the code >> for >> handling arrays awful. >> >> Similarly, Character'Size = 9 on that machine. > > That sounds like a non-conformance, at least if the SP Annex > is supported. Maybe you mean X'Size = 9, where X is of > type Character? You'd certainly want 'Component_Size = 9 > for array-of-Character. You're probably right. I never implemented Ada 95 'Size because it is meaningless. Janus/Ada 'Size is essentially what GNAT calls 'Object_Size, and it is used for all allocation/representation decisions in the absence of representation clauses. (Indeed, what I intend to do "someday" is covert the existing Size code to be reported as Object_Size, following the model of the rejected AI on that attribute, and then implement 'Size as mandated by the Standard, for no purpose other than matching the legality rules of the Standard. (Object_Size would continue to be the significant factor in object layout.) Randy.
From: Jeffrey Carter on 10 Aug 2010 18:24
On 08/10/2010 02:36 PM, Randy Brukardt wrote: > > It was originally 36-bits (and really ought to have been 36), but that > caused our front end to make strings with 36-bit characters. So ultimately, > we changed it to 9-bits, and put strong alignment requirements on 18-bit and > 36-bit integers. That fit better with the existing compiler implementation. > (The change took more than 6-months of work, however, and really delayed the > completion of the compiler, probably a contributing factor to none of the > intended customers ever buying it.) 36-bit characters. Ouch. Reminds me of the advice in /Software Tools/ to use the R format for characters in FORTRAN via Ratfor; on the CDC machine I was using, that would have put each character in its own 60-bit word, so I did otherwise. (CDC used 6-bit characters.) -- Jeff Carter "Strange women lying in ponds distributing swords is no basis for a system of government." Monty Python & the Holy Grail 66 --- news://freenews.netfront.net/ - complaints: news(a)netfront.net --- |