Olin Lathrop wrote:
> Tom=E1s =D3 h=C9ilidhe wrote:
>   =

>> I write fully-portable C code that will work on every
>> conceivable implementation of the C Standard, regardless of
>> endianness, number system, size of byte, character set.
>>     =

>
> Oh, and how do you deal with multiple address spaces?  I thought the C
> standard doesn't consider that.


The C Standard only talks about how a program should behave; it doesn't =

restrict the way in which the compiler achieves the behaviour. More on =

this below.


>   What exactly is a VOID* on a PIC?  If you
> really want to force a single descriptor for everything the processor can
> address than you have to include bits to identify the address space and
> process every indirect reference laboriously at run time.
>   =



Let's say we had a pointer variable such as:

    void *p;

If the compiler can see that "p" only ever points to a certain address =

space, then it can optimise the code accordingly. If however this =

variable is used in one place to store an address within a certain =

address space, and then again is used to store a different address in a =

different address space, then yes you're correct in saying there'd need =

to be extra information to indicate the address space. Perhaps it would =

be represented something like:

struct GenericPointer {

    bit address_space;

    union {
        Pointer1 p1;
        Pointer2 p2;
    };
};

Or then again, the compiler might end up creating two code branches, one =

for each address space.

Another example of compiler intuition is when it comes to integer =

promotion. Take the following for instance

    char unsigned a =3D 7, b =3D 2, c =3D 6;
   =

    a =3D b+c;

A standard-compliant compiler is obliged to implement integer =

promotion... but the program only has to behave "as if" the integer =

promotion was applied. In the example above, the compiler can work =

solely with 8-Bit numbers because it sees that there's no need to use a =

16-Bit one. The PIC C compiler does this.


> If your force compilers for machines like PICs to be absolutely standards
> compliant (if that is even possible), then you end up with some very
> inefficient machine code.  That can be a big deal on small resource-limit=
ed
> machines like PICs.


You'd be surprised how intuitive a compiler can be. The PIC C one is =

particularly good. It can definitely produce better assembler than I can.

-- =

http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist