From: Niklas Holsti <niklas.holsti@tidorum.invalid>
Subject: Re: Interfaces.Shift_Left
Date: Sun, 18 Dec 2011 22:47:15 +0200
Date: 2011-12-18T22:47:15+02:00 [thread overview]
Message-ID: <9l71m2FlhuU1@mid.individual.net> (raw)
In-Reply-To: <jce32s$brp$1@munin.nbi.dk>
On 11-12-16 02:23 , Randy Brukardt wrote:
> "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.
Ooh, harsh words. I'm trying not to take offence.
Of course I hide the implementation in an "extract field" function with
the bit numbers as parameters. My code typically decodes machine
instructions from the instruction set of some processor; the user manual
of that processor is the specification for my SW; the user manual
normally shows the format of a given instruction by a figure of the
instruction with the fields indicated by bit numbers; there is an
immediate correspondence between this figure and the calls of the
"extract field" functions. Very easy to write, check, and maintain, in
my experience.
>> 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.
"All the world is a VAX -- no, an Intel -- no, an Xxx", eh?
I do not want to write programs that have such an implementation
dependency. I wouldn't go so far as to call such code "junk", but it
would be as bad as assuming that Integer is 32 bits.
>> 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.)
I'm sure that is the intention. But as I haven't been able to understand
the conditions under which Bit_Order works, I haven't dared to rely on
it. Maybe I could understand Bit_Order if I tried harder, but then
there's the other factor:
>> 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
Sure, run-time is no problem; the problem is having to write a lot of
type declarations, plus their representation clauses. There's just much
more text, more type names, more component names, which to me have
little benefit. Each of these types and components would be used only
once, in the Ada code that translates an instruction of that format into
my internal representation.
> and IMHO they're still
> more readable than a bunch of shifts or multiplies.
I agree, if the shifts and masks would be written in-line, which I don't
do. I write calls to my "extract field" function instead, which I find
very readable and easy to compare to the specification.
--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
. @ .
next prev parent reply other threads:[~2011-12-18 20:44 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 ` Interfaces.Shift_Left Randy Brukardt
2011-12-18 20:47 ` Niklas Holsti [this message]
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