Array at specific address

[Richard Heathfield]

char *p = (char *)10000; is legal C, but C offers absolutely
no guarantees that the address you've forced p to point to is
a good place for storing data. This is the kind of trick that
it is best to avoid. For one thing, it's considerably less
portable than Brazil. For another thing, even if it's legal to
write to that space on your system (and it probably isn't, on
modern systems), where do you draw the line? p[100]? p[1000]?

(On the other hand, so-called "badly-behaved" MS-DOS programs
used to do this sort of thing all the time - for an
excellent-at-the-time reason which has become more or less
irrelevant nowadays.)

It's not unusual to see this kind of code used in embedded
systems for which I/O and/or control spaces have been memory
mapped. I agree that it's not portable; but have found it
extremely useful within that limited context.

Oops. Sorry, yes, I'm afraid I was thinking of desktop systems and up. In
the embedded world, hackery of this kind is indeed still invaluable.
Indeed, there are embedded systems nowadays which are far more powerful
than MS-DOS boxes ever were, and perhaps MS-DOS should be thought of as an
embedded system with delusions of grandeur. (I should add that I have a lot
of time for MS-DOS; I regard it with considerable fondness, and indeed
still program for it occasionally.)

 

[Mark McIntyre]

No, the result of the directive is to introduce a macro called MyArray.
That's all.

My apologies - I thought you were trying create an array *at a
specific memory location*, like the OP asked. I obviously assumed
therefore that one had to actually do that, instead of merely
'introducing a macro'.....

 

[Kevin Easton]

My apologies - I thought you were trying create an array *at a
specific memory location*, like the OP asked. I obviously assumed
therefore that one had to actually do that, instead of merely
'introducing a macro'.....

You can't do that on the DS9k!

My intention was merely to show as much of the solution as is possible
in portable C - since the very idea isn't portable there sure isn't a
full answer that's portable.

- Kevin.

 

[Mark McIntyre]

You can't do that on the DS9k!

Sorry, we were at cross purposes. I thought you were claiming
portability for the macro.

 

[Chris Torek]

I cant't do MyArray[2048] = {0x00} @ 0xFFFF1199 :-(
I am using the gnu compiler.

... If you have to have it as an array then check with a newsgroup that deals
with your compiler. You can sometimes define a section of data to a linker
section name (.text, .bss. data, etc.) and then instruct the linker to put
that section at a specific memory location. This is highly dependent on
your linker and completely off topic for comp.lang.c.

Assuming he is using the GNU binutils linker as well as the GNU
compiler suite, there is indeed a way to do it. The C code
portion can consist entirely of:

extern char MyArray[2048];

with linker directives to put the known name at the chosen address
and (if needed, and if the target link format is capable) to fill
the chosen address with 2048 zero-bytes. Since the binutils linker
directives are not C, you will have to go somewhere else for that
part.

(For more complex cases, one can also use gcc's __attribute__
extension to assign linker sections, as noted above, but beware:
this is buggy in various versions of gcc.)

In general, it is probably better to access specific regions of
memory or memory-mapped I/O via "volatile unsigned char *" pointers
and the like. But on specific architectures, absolute addressing
modes sometimes generated via the "extern char A[]" method may be
desirable in certain cases. (As you might surmise from the amount
of weasel-wording here, this can get quite dicey. Not only do you
need to know everything about the target CPU and hardware, you also
need to know precisely what comes out of the compiler under each
of its different optimization and code-generation models. With
gcc, for instance, using -fpic or -fPIC could really wreck things.)