That's very, um, far back in the day. It hasn't been an issue on x86 CPUs since the 386 or 486.
-Eric
On Oct 28, 2005, at 11:52 AM, Joseph Oreste Bruni wrote: Back in the day, x86 programmers had to worry about "near" and "far" pointers. Is this something that will be an issue on OSX-intel or does the compiler take care of that?
-Joe
On Oct 28, 2005, at 11:50 AM, Eric Albert wrote: Actually, on Intel nearly all types are the same size as they are on PowerPC. This is intentional -- if we didn't do it this way migrating to Intel would be a lot more difficult.
The one difference is the C 'bool' type, which is one byte on Intel and four bytes on PowerPC (but usually one byte in CodeWarrior). Also, struct padding can be different in some cases.
(And then there's the whole endianness thing....)
-Eric
On Oct 28, 2005, at 11:16 AM, Joseph Oreste Bruni wrote: assert() is your friend. You can also add things like "#if" to check the sizes of things at compile time. This is going to get really interesting on x86, I think.
On Oct 28, 2005, at 11:09 AM, Mark Wagner wrote: Thanks. I found the memory bug that's been plaguing me for some time: CodeWarrior/CFM does not provide a "uint" type, so our code defines it in a header file as being 16 bits. GCC/Mach-O *does* provide it, so our header file doesn't -- but it's now 32 bits. Needless to say, this causes problems when trying to load 16 bits of data from a binary file.
Thanks, Mark Wagner
_______________________________________________ Do not post admin requests to the list. They will be ignored. Help/Unsubscribe/Update your Subscription:
_______________________________________________ Do not post admin requests to the list. They will be ignored. Help/Unsubscribe/Update your Subscription:
|
