1. Home
  2. Embedded Programming
  3. @far directive not working as expected

@far directive not working as expected

Here is a good one for you guys......(I would ask in comp.lang.c, but not sure this is ANSI C and those guys get weird if it isn't STRICTLY C related).

I have a local function defined with the @far directive, a local prototype of the same function @far and looking into the map file the function has a f_ indentified. It is using 3 byte(ie far) addressing, BUT it stuck the bloody thing in near space.

I am using a Motorolla 9s12DG128 with the cosmic compiler v 4.6a.

I assume that Cosmic is doing some sort of optimization thing for me, but I don't know why or how to tell it that I really want it to put this in far space. I #pragma'd it to (ftext) but it still placed it in the .text section.

Any ideas? I have used this format in other context and it has worked as I would expect it to, so there is something unique causing it to do this.

JW

REMOTESTART_FAR void RemoteStart(BOOL coolantValid, UINT8 coolantTemp,\ BOOL ambientValid, UINT16 avgAmbient, UINT16 ignOffTime);

REMOTESTART_FAR void RemoteStart(BOOL coolantValid, UINT8 coolantTemp,\ BOOL ambientValid, UINT16 avgAmbient, UINT16 ignOffTime) { function stuff }

f_RemoteStart 0000519a defined in _output/\RemoteStart.o section BASE1 (.text)

Reply to
cyberzl1
Loading thread data ...

It's worse than "not strictly" C related --- it has basically nothing to do with the programming language C at all. It has to do with details of the the non-standard behaviour of a particular programming toolchain. You don't seem to even have established whether it's the compiler or the linker whose behaviour you object to.

And why is that bad? Is that architecture of addressing functions as "far" if they are in "near space"? Are you running out of "near" space?

Now here's some information you really should have put a lot further up in your post. Possibly in the Subject:.

--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.
Reply to
Hans-Bernhard Broeker

I am not sure, but I think it is the linker whose behaviour is causing me trouble. It may be my syntax and/or the compiler. I really don't know.

That is bad because I wanted it in far space. I tried to put in far space for a reason. Near space is my limiting factor right now.

OK, maybe should have been higher in the post. At least I included it.

Reply to
cyberzl1

^-- insert "incapable" here

That's not bad in and of itself. It's only bad if this actually prevents the program from working. Does it?

So: is the link failing, or the program failing to run, because of this? Have you, or have you not, actually run out of near space?

Assuming "near space" is a subset of "far space" on your architecture, a linker that fills up unused parts of near space with functions from "far" space doesn't do anything wrong.

--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.
Reply to
Hans-Bernhard Broeker

Agreed that in itself is not necessarily bad. Bad, because it is putting more stuff in near space than will fit. Part of the issue is that "near space" overlaps the last two pages of far space. Basically the last two pages of memory can be addressed w/ either addressing method to reach code/data in them.

This is preventing the program from working. It is creating an overlapping segment which is also concerning me. I have had the linker warn me before when it has done this, but it is not for this scenario(I think because of the two different addressing schemes it is not recognizing that it has done so).

I have this configured to place all far space code starting at the "beginning" of far code space. It should place everything in far code until it is out of space. I have put too much stuff in far space (on purpose) and received the expected errors.(using the max size options) I am not running out of far space, so I don't know why it selectively choose to put this singular function in near space.

JW

Reply to
cyberzl1

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.