Re: 64bit access to an array of 8bit values

["Jeffrey Creem" <jeff@thecreems.com>]

"John R. Strohm" <strohm@airmail.net> wrote in message
news:482822EEF13389AC.7CF0F33D21F3D96D.C977F409C9057456@lp.airnews.net...
> Well, that is precisely what I did.  After explaining why the pointer
> hacking he wanted to do did not work in the EXTREME GENERAL case, I showed
> several alternatives that all WOULD work in the EXTREME GENERAL case.

Sorry..Upon re-reading I see you did give the correct  alternative

"The first easy answer is that you model your memory as an array of Bit64,
and do the necessary bitpicking to extract the Bit8, Bit16, and Bit32 values
yourself.  If your machine doesn't support Bit64-like objects, then do it as
Bit32 and hack around the Bit64 access.

The other easy answer is that you model your memory as an array of Bit8, and
then you build up your Bit16, Bit32, and Bit64 accesses by doing multiple
Bit8 fetches and stores."

(Note that the statement "The Ada compiler is not required to allocate
precisely one byte per array
element, and it probably didn't." is still incomplete since it fails to
discuess various rep spec issues). In fairness the rep
spec issues are mostly irrelevant with the solution you propose..

However, my initial concern still stands (and this is not just true here but
I've seen similar discussions crop up
on the C++ and other mailing lists)... The problem with the way the response
is phrased is people walk away with the understanding that they can not use
the simple straightforward approach in Ada so they have to resort to
something more complicated. In fact, the problems you point out are common
to all languages (with the possible exception of Java which always runs with
the same endianness regardless of host but then of course would probably now
allow the evil pointer arithmetic that seemed to be desired so perhaps in
that case the answer really could have been you can't do it like
that  in XX lang).


>
> The object of programming in a high-order language is that you DO *NOT*
WANT
> to deal with the idiosyncrasies of the target machine's architecture.  To
a
> first approximation, 99.9% of the code in a serious embedded system is
> totally, utterly, completely INDEPENDENT of the target architecture.  The
> other 0.1% (say 1000 lines out of a million LOC system) is heavily
> target-dependent, and has to cope with it all.  For that 0.1%, Ada
provides
> machine code insertions, and every implementation I have seen provided a
> capability for interfacing to assembly language code ("pragma linkage", as
I
> recall: it has been several years since I last dealt with Ada and assembly
> language interface).  (Yes, I have done Ada machine code insertions, on a
TI
> 320C40.  It was NOT fun.  We had a very tight limit on the amount of real,
> live assembly language we could write, but machine code insertions didn't
> count against the limit, so...)
>
> Close to thirty years ago, one of the Big Names in computer science had an
> article in "Software Practice and Experience".  I think it was Nicklaus
> Wirth.  They had just ported their PASCAL compiler to a PDP-11, and were
> testing something that had to do with character strings.  They set up what
> they THOUGHT should have printed as "ABCD", and were quite disconcerted
when
> it printed "BADC".  They asked, in the article, for enlightenment as to
what
> had gone wrong.  THEY WERE MYSTIFIED.  This was in the early days, when
the
> problems created by the little-endianness of the PDP-11 were still eating
> everyone alive.  (In fact, the terms "endian-ness", "little-endian", and
> "big-endian" were not yet in common use in computing.)  The catch is that
> they had written code that implicitly assumed big-endianness, because
every
> machine they'd ever encountered was big-endian.  (If memory serves me, the
> PDP-11 was the very first little-endian architecture.)
>
> The underlying problem with what the original poster wanted to do was
this:
> the endian-ness of his emulated machine MAY OR MAY NOT have matched the
> endian-ness of his target hardware.  With a pointer-coercing scheme, you
> explicitly accept whatever endian-ness the target hardware imposes on you.
> This is not necessarily good: consider what happens, FOR EXAMPLE, when you
> try to model a (big-endian) 68020 on a (little-endian) Pentium.  It gets
> even worse if you have a process with a mode bit that SWITCHES endian-ness
> on the fly for you.
>
> Running a pointer-coercing scheme also runs the risk, as someone else
> pointed out, of encountering SIGBUS traps, if the emulated machine allows
> unaligned multibyte transfers but the target hardware (running the
emulator)
> doesn't.  Try simulating a 68040 (which allows unaligned transfers) on a
> 68000 (which doesn't).
>
> "Jeffrey Creem" <jeff@thecreems.com> wrote in message
> news:YSch8.50282$%b6.13414165@typhoon.ne.ipsvc.net...
> >
> > > What this taught me is that solutions that work "most of the time"
DON'T
> > > work ALL of the time, and the right answer is never be satisfied with
> > > something that doesn't work ALL of the time.  Correctness is a binary
> > > property.
> >
> >
> > I don't entirely disagree but when face with an answer like "Sorry you
> can't
> > do that [in Ada]" a
> > person asking such a question will go off and say well I better do that
in
> C
> > then when in reality all of the
> > problems you bring up would exist there as well....Your answer was not
"No
> > do it this way instead" but
> > rather "You can't do that". I suspect following that advice I could
> convince
> > myself that I can not write any software
> > so perhaps I should be a gardener. (After all, Hello World will not work
> on
> > an embedded machine with no display so it is clearly not possible to
write
> > Hello World in Ada)
> >
> >
> >
>
>