From: "Randy Brukardt" <randy@rrsoftware.com>
Subject: Re: Interfaces.Shift_Left
Date: Thu, 15 Dec 2011 18:23:54 -0600
Date: 2011-12-15T18:23:54-06:00 [thread overview]
Message-ID: <jce32s$brp$1@munin.nbi.dk> (raw)
In-Reply-To: 9ktu5mFn31U1@mid.individual.net
"Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message
news:9ktu5mFn31U1@mid.individual.net...
> On 11-12-15 00:49 , Randy Brukardt wrote:
>> "awdorrin"<awdorrin@gmail.com> wrote in message
>> news:a76daa61-49f7-4235-af65-11973a012f35@v29g2000yqv.googlegroups.com...
>>> I understand what you are saying and I do agree in theory.
>>>
>>> The situation is that bit shifting is being used to retrieve data of
>>> various bit lengths and positions from compound records.
>>>
>>> For instance, retrieving a 6-bit signed value from a 32-bit field.
>>
>> Right. This definitely should be done using record representation clauses
>> if
>> there is a choice.
>
> I'm sorry to say that I disagree, and now always use the shift-and-mask
> method.
Might as well write in C then, this sort of code is complete, unmaintainable
junk.
> I used to be charmed by record representation clauses, until I wanted to
> write Ada 95 code that was portable between machines with different bit
> numbering orders.
It's true, that's a problem. Luckily, it's not a real problem in practice
for the vast majority of users, since pretty much all popular machines these
days use the same bit numbering.
> I know that it is claimed that record representation clauses can be
> written to be portable between different bit numberings. But in my
> opinion, the schemes that do not use the Bit_Order attribute make the
> representation clauses ugly and hard to write and read, while the RM
> language that describes the Bit_Order attribute and its effects has
> surpassed my understanding whenever I've tried to read it -- I simply
> could not be sure that it would have the effect that I wanted.
It will have the right effect or be illegal. (At least that was my
understanding.) The problem is that the non-default bit ordering makes it
trivial to declare discontiguous (from the persepective of the default
bit-ordering) components, and we didn't want to force compilers to support
that sort of stuff. There is little customer demand for that sort of thing
(most of the ones that exist are like you and gave up completely wanting
more control than the language could possibly provide), so it didn't make
sense to require the effort.
> I still would like to define the bit-level structure of data in a
> declarative way, rather than with field-extraction and field-insertion
> operations, but I have reluctantly concluded that the operational method
> is better for portable Ada programs, at least in my applications.
>
> Another factor in this decision is that in my applications, the raw data
> (machine instructions for various processors) can actually have several
> different structures (instruction formats), so an approach using record
> representation clauses needs as many different record types and unchecked
> conversions from the raw data (bit-strings or words) to the appropriate
> record type. The operational approach entirely avoids these conversions.
Of course, the vast majority of Unchecked_Conversions generate no code at
all, so these conversions have no run-time impact and IMHO they're still
more readable than a bunch of shifts or multiplies.
Anyway, I understand that everyone's mileage may vary. I doubt that many
applications have the problem of decoding data that are both in the wrong
bit-order and are unknown at run-time.
(Truth-in-advertising provision: most of the Janus/Ada compiler uses
multiplies and divides to create machine instructions, because early
versions of Janus/Ada had no support for record representation clauses or
any other bit operations at all. We used assembler code whenever those
operations were unavoidable -- hardly an ideal approach for portability
reasons. Later versions (like the never-finished 68K and SPARC codegens)
used record rep. clauses; I recall we had some issues with non-default
bit-ordering but don't remember anymore how we solved them.)
Randy.
next prev parent reply other threads:[~2011-12-16 0:23 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-12 22:30 Interfaces.Shift_Left awdorrin
2011-12-12 23:34 ` Interfaces.Shift_Left Simon Wright
2011-12-13 1:36 ` Interfaces.Shift_Left Adam Beneschan
2011-12-13 12:00 ` Interfaces.Shift_Left Brian Drummond
2011-12-13 13:15 ` Interfaces.Shift_Left awdorrin
2011-12-13 21:48 ` Interfaces.Shift_Left Randy Brukardt
2011-12-14 18:28 ` Interfaces.Shift_Left awdorrin
2011-12-14 22:49 ` Interfaces.Shift_Left Randy Brukardt
2011-12-15 9:51 ` Interfaces.Shift_Left Niklas Holsti
2011-12-16 0:23 ` Randy Brukardt [this message]
2011-12-18 20:47 ` Interfaces.Shift_Left Niklas Holsti
2011-12-20 0:38 ` Interfaces.Shift_Left Randy Brukardt
2011-12-20 2:18 ` Interfaces.Shift_Left Shark8
2011-12-20 10:08 ` Interfaces.Shift_Left Dmitry A. Kazakov
2011-12-20 19:38 ` Interfaces.Shift_Left Niklas Holsti
2011-12-20 20:46 ` Interfaces.Shift_Left Niklas Holsti
2011-12-20 21:13 ` Interfaces.Shift_Left Simon Wright
2011-12-20 21:08 ` Interfaces.Shift_Left Simon Wright
2011-12-20 23:26 ` Interfaces.Shift_Left Randy Brukardt
2011-12-20 23:36 ` Interfaces.Shift_Left Randy Brukardt
2011-12-21 0:44 ` Interfaces.Shift_Left Georg Bauhaus
2011-12-21 7:23 ` Interfaces.Shift_Left AdaMagica
replies disabled
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox