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

["John R. Strohm" <strohm@airmail.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.

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)
>
>
>