Re: working with addresses

From: pcrAKAJumbo (nospam)
Date: 01/12/04

  • Next message: Jenski182: "Dir command" 
    Date: Mon, 12 Jan 2004 01:49:08 -0000

    "Josh Sebastian" <curien@cox.net> wrote in message
    news:pan.2004.01.12.00.39.00.359025@cox.net...
    > On Mon, 12 Jan 2004 00:18:20 +0000, pcrAKAJumbo wrote:
    >
    > > "Richard Heathfield" <dontmail@address.co.uk.invalid> wrote in message
    > > news:btsfup$ieg$1@hercules.btinternet.com...
    > >> pcrAKAJumbo wrote:
    > >
    > > But if you CPU is addressing in 32 bit mode you cannot simply start
    > > addressing with 10 bit addresses.
    > > That's nonsense.
    >
    > 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.
    >
    > >> 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 but in this example I am *obviously* talking about a PC with a 32
    > > bit address bus.
    >
    > Is an "address bus" what addresses use to get to work in the morning? ;-}
    LOL

    >
    > > 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.
    >
    > >> 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.
    >
    > > now I don't claim to be an expert on CPU's
    >
    > Noted.
    No need to note it, it need not concern you.
    >
    > > 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.

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

    >
    > > But guarantee is a bit of a strong word , the standards do not guarantee
    > > anything
    >
    > The "guarantee" is just like a money-back guarantee at Wal-Mart: if you're
    > compiler claims to follow the standard and doesn't, you can get your money
    > back. :-}
    LOL no its not like that at all. They were saying that because they ISO docs
    state that this or that should happen then you as a general punter are
    guaranteed that this or that will happen. This is almost true if every time
    they were to make this statement they made it in full i.e: You are
    guaranteed that this will happen if you're compiler is 100% standard
    compliant. But we all know that this is never the case and there there can
    be no guarantee.
    And also they don't make the statement in full generally use this term for
    everything that is documented in the standards, which is bull***. Thats
    like saying If you build your house to the building standards you are
    guaranteed it won't crash down, then the next week a tremendous earthquake
    smashes it to smithereens . Do the standards people offer you a new house?
    I think not. Just as if your program crashes into a frozen screen of garble
    do you receive any funds? No I think not. :)

    >
    > "Guarantee" does not mean that there exist no counter-examples.

    What's that supposed to mean?
    I know what guarantee means I have a dictionary here you know :-)
    3 actually.

  • Next message: Jenski182: "Dir command"