Re: Memory debuggers for MacOS 10.3.9
Re: Memory debuggers for MacOS 10.3.9
- Subject: Re: Memory debuggers for MacOS 10.3.9
- From: Mark Wagner <email@hidden>
- Date: Fri, 28 Oct 2005 14:16:39 -0700
It's still an issue if you're writing bootstrap code. For legacy
reasons, all x86 CPUs start up in real mode (segmented memory). For
everyone else, it hasn't mattered since the 80286: the 386 supported
protected mode and flat memory addressing.
--
Mark
On 10/28/05, Eric Albert <email@hidden> wrote:
> 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.
> Xcode-users mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Xcode-users mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Xcode-users mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
>
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden