15 Oct
2011
15 Oct
'11
8:06 p.m.
On 15/10/11 9:17 PM, Dave McGuire wrote:
On Oct 15, 2011, at 8:56 PM, "Chuck
Guzis"<cclist at sydex.com> wrote:
This was indeed done in C compilers on word-addressed architectures,
such as DG Nova, which had a software convention for byte addressing.
The fact that C targeted word-addressed architectures likely leaves its
mark in certain liberalities of the standard.
Chris Torek was fond of writing anecdotes about arcane C platforms -
google his Usenet posts.
--Toby
On 15 Oct 2011 at 17:57, Dave McGuire wrote:
This is not a fault of C. ;) How would you implement byte pointers on a Cray 1 in
some other language? ;) That said, also, some strcpy() and memcpy()
implementations do deal
with overlapping source/target regions just fine. They're slower,
though...once again spending cycles to compensate for the shortcomings
of programmers who would be better suited to flipping burgers than
writing software.
And sometimes there are functions that are guaranteed to work, no
matter the overlap (e.g. memmove() vs. memcpy() ).
But what kind of person would use the given sample loop, rather than
a library routine?
When working with C on an unfamiliar platform, I study the generated
code both to get a handle on how the compiler handles code generation
for the platform. I realize that this is probably considered to be
"old fashioned" however.
C was a great assembler for the PDP-11, but for other platforms,
maybe not so much. How, for example, do you implement byte
pointers on hardware that only addresses words? (e.g. Cray 1). Most 8080 Cs were perfectly dreadful--and
I've been surprised to see
C implementations on 8-bit PIC hardware.
Yes, compiler technology has come a really, really long way since the 8080 days.
-Dave