2 Jul
2012
2 Jul
'12
10:10 p.m.
On 07/03/2012 12:49 AM, Sean Conner wrote:
It hasn't been that bad. In fact, the testing tools I wrote (that's my
job---to test the code the other developers write) were more portable than
the code I was testing! (our lead developer has this insane embedded mindset
where I swear he thinks we're writing our code for 1MHz 6502s instead of
64bit multicore SPARC but that's a rant for another time; he didn't bother
with byte swapping (because every cycle is sacred) on the network protocols
because, well, hey, we're using only SPARCs, until that wasn't the case).
Ha, that guy sounds like me, but I always use ntohl()/htonl() and
ntohs()/htons(). :)
I seem to recall the Latice C compiler for the Amiga (I still own it)
spent a chapter or two on linking with the output from other compilers that
may use different sized ints (68000, internal 32 bit, external 16 bit bus,
so arguments could be made for using either size for an int).
So it was capable of interoperating with both? That's pretty cool.
When I started caring a lot about portability (which I do, lest
someone assume otherwise from my dislike for the newfangled uint32_t
business) nearly all of my work was on 68020-based machines with either
Sun's unbundled C compiler or GCC.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
It was thus said that the Great Dave McGuire once
stated:
Well, at work, we develop code that has to run on both 32 and 64 bit
systems (Pentium and SPARC, so I get the fun of byte swapping too!). I
don't even know what the size of a 'long' is on the 64 bit system (but I
don't really have to care when I can select uint32_t or uint64_t as needed).
I *do not* envy you there. ;) -spc (If I recall correctly, there were several
different compilers for
68k based systems where an 'int' could be 16 bits or 32 bits ... )
I don't recall any of those...any recollection of which ones?