Re: working with addresses

From: Martijn Lievaart (m_at_remove.this.part.rtij.nl)
Date: 01/12/04 

Date: Mon, 12 Jan 2004 09:53:31 +0100

On Mon, 12 Jan 2004 01:49:08 +0000, pcrAKAJumbo wrote:

>> Pentium4 CPUs have two addressing modes: 32-bit and 36-bit.
>> In the early x86 days, there were 16- and 32-bit addressing modes.
>>
>> And that's just a couple of examples for PCs. If you leave the x86 world,
>> it can get even more convoluted.
>
> Yes but it is not a trivial operation to switch addressing modes.
> If a program is designed to work in 32 bit mode it won't work in 16 bit
> mode.

Not relevant. If a compiler outputs code that uses 36 (or 48! the Pentium
has those to iirc) bits pointers, there probably is a use for it.

Most OSses will set up an environment that requires a (some) certain
mode(s) of the CPU. Either the compiler must comply with this, or it has
to talk to the OS to make the OS comly to the compilers rules.
DOS-extenders are a good example of the latter catagory.

So a compiler is targetting a certain environment. (It may even target
more than one environment, bet let's leave that aside for now). If a
compiler targets an environment where 36 bit pointers are used, it is up
to the compiler/OS combo to make it work.

>>
>> >> in a 32-bit array, he would prefer to see:
>> >>
>> >> 00000000110011101011001010111110
>> >>
>> >> rather than
>> >>
>> >> 11001110101100101011111000000000
>> >>
>> > Too right I don't understand it.
>> > What the heck are you talking about now? These are two completely
>> > different numbers.
>>
>> They both have the same bit-sequence, just aligned differently.
>
> They are two completely different numbers.
> At a quick glance it looks like the lower one is the upper multiplied by 2^8
> or something.

Yes, they are different representations of the same number. In pointer
land, strange and wonderful representations exist. 386 32bit-flat
addressing has the advantage that most weirdness goes out of pointer
representation, which is why every 386 OS in common use today uses that
memory model. But never make the mistake of thinking that this is the only
valid model for addressing memory. Other schemes do exist and the standard
alows them.

>>
>> > I claimed that on a 32 *system* the pointers will be 4 bytes
>>
>> My 32-bit system can use 36-bit pointers. Chances are, yours can too (P4s
>> being the most common desktop 32-bit CPU these days).
>
> Yes well as I said I am not an expert but I don't think that changing the
> size of a pointer during program execution is a trivial task. As for older
> processors it was actually very difficult to switch modes in some cases.
> Maybe newer ones will produce smething completely different.

32 bit systems exist where pointer size is 64 bit (32 bit pa-risc). But as
noted above, just because you think of your processor as 32 bit, that does
not mean that all pointers are 32 bit. It's up to the compiler/OS combo.
You can make claims about particular systems (all my systems use 32 or 64
bit straight pointers with no pointer weirdness), but making a general
claim is not possible.

>> >> Consider a system which stores long * in 24-bit pointers and int * in
>> > 32-bit
>> >> pointers. On such a system, converting an int * into a long *
>> >> inevitably loses information. Such a conversion is "lossy". A
>> >> "lossless" conversion
>> > is
>> >> one which does not lose information.
>> >>
>> > But there is no such a system. CPU's operate in specific modes
>>
>> No, they don't.
>
> Not them all I suppose but the ones that don't have different modes are
> probably fixed to a specific size of address bus.

Those are the most problematic most of the time. The tricks these chip
designers think of to get around these limitations. The tricks compiler
writers have to think up to get around these limitations.

>> > but I know that with the Intel CPU
>> > you need to change the CPU mode to change memory addressing size
>>
>> No, you just need to use certain CPU instructions.
> Yes this is what is meant by changing modes.
> I.E: Switching the Intel CPU from real mode to protected mode which happens
> to be INT 15 - AH 89H in Intel ASM assmebly instructions but there is alot
> more to it than simply executing a CPU instruction. You need to set up
> Descriptors and all sorts that I don't really want to get into.

Don't. You obviously don't know what you're talking about.

> So I disagree with you and I think your attempt at trivialising cpu mode
> switching is misinformative.

There is nothing trivial about mode switching, but it is not relevant.

1) The compiler/OS combo does it for you if it is relevant.

2) On most processors, you can use different addressing modes by using
different instructions. The compiler is free to exploit this. No
'switching' in the sense you used it necessary.

3) Even on 32 bit processors, pointers can take a lot of representations.
The fact that most OSses on a i386 do not use this, does neither mean it
cannot be done, nor that it isn't done, nor that the standard disallows it.

HTH,
M4

Relevant Pages

  • Re: new IL: C (sort of...).
    ... only for "recent" Pascals, ... far pointers weren't really limited, ... in my compiler, I made wchar_t a builtin type (in most cases, aliased to ... I could very well include builtin "managed strings" in the new IL. ...
    (comp.lang.misc)
  • Re: new IL: C (sort of...).
    ... and the frontend compiler needs to be able ... Having very limited pointers is a fact of life in a VM language though, ... vague claims about Pascal's pointer support. ... That is pretty normal for standards (the ...
    (comp.lang.misc)
  • Re: code optimiation
    ... Given that the compiler can often optimise the generated code to use the best sized types available, it's seldom worth specifying "fast" types explicitly. ... pointers and floating point types whose "zero value" might not be all- ... instruction, so the assembler produced for *p++ when used as the ... It will do the same job, and let you write the source code using proper array constructs. ...
    (comp.arch.embedded)
  • Re: A taxonomy of types
    ... I am describing how to represent the representation (and, ... if the system follows static typing rules (such as in a compiler), ... so, the hardware sees pointers and pointer arithmetic, but the compiler ... "Besides the char types, up to three sizes of integer, declared short int, ...
    (comp.lang.misc)
  • Re: new IL: C (sort of...).
    ... Having very limited pointers is a fact of life in a VM language though, ... only take about 1/2 the register space (presently, ... nearly any compiler can be written "to the standards", ... That is pretty normal for standards (the ...
    (comp.lang.misc)