🚀 go-pugleaf

alan@elroy.Jpl.Nasa.Gov (Alan S. Mazer) writes:

>>>>We're programming a device that has a RAM cache at address 809800H.
>>>>Is it legal to address this memory in C as follows?
>>>>#define ON_CHIP 0x809800
>>>>...
>>>>   float *oc_ptr = (float *) ON_CHIP;
...
>>In all such cases, an integer *value* is being cast to a pointer type.
>>There are no literal pointer constants (except the null pointer) in C.
>>The results of casting an integer value to a pointer type are
>>implementation-defined and not portable.

>Okay, I'll agree with this.  But the net effect is the same.  If the constant
>fits in one of those types (if it doesn't we'll get a compile-time error),
>then the value can be usefully assigned to a pointer variable and used.  Note
>that this code obviously is unportable to begin with.  We're writing to a
>specific location in memory.  The danger in mixing pointers and ints is that
>either may be too short to hold the other.  In this case, assuming the poster
>knows what he's doing and isn't addressing outside his memory space, it's a
>moot point.  If pointers are too small to hold the address specified, he
>doesn't know what he's doing.  If they're not, then it works fine and there's
>no ambiguity.  In short, there is still no problem that I can see.

The problem is that you have no assurance that the compiler expects to
see machine addresses expressed as simple integers.  Compilers commonly
allow that but are not required to.  On a segmented or otherwise
complex architecture, an address might need to be broken into several
parts, and a simple integer value might not have the results you expect.

Just because the programmer thinks of the absolute machine address as
0x809800 does not mean that the compiler will recognize the address
when represented that way.  You have to read the compiler manual to
find out how machine addresses should be expressed.

Even on as common a machine as a PC I may have to jump through a few
more hoops to represent an address properly depending on the memory model.
For example, suppose I want to reference 1 byte at absolute address
0x1234.  If I naively write
	char *p = 0x1234;
it might point to the byte in my global data segment at offset 0x1234
rather than to absolute address 0x1234.  I need instead to do this:
	char far *p = MK_FP(0, 0x1234);
where MK_FP is a compiler-supplied macro which makes a far pointer out
of a segment and offset.  This isn't portable to any other system, but
the naive first attempt won't always work on a PC.

If I am programming on a Unix system, I can't get to absolute machine
addresses this way at all.  Every program address is a virtual address,
and I can't predict where the physical address will be.  I have to go
via the memory-mapping system to get to a machine address, and the
details vary with the flavor of Unix.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com