Sign in

username:

password:



Not a member?

Search adsp



Search tips

Subscribe to adsp



adsp by Keywords

AD1819 | AD7332 | ADSP-2106 | ADSP-21060 | ADSP-21065L | ADSP-2116 | ADSP-21160M | ADSP-2181 | ADSP-218x | ADSP-219 | ADSP-2199 | ADSP219 | BF531 | BF532 | BF533 | BF535 | Blackfin | FFT | JTAG | LDF | SDRAM | SHARC | SPORT | UART | VDSP++ | VisualDSP

Discussion Groups

Discussion Groups | Analog Devices DSPs | AW: Far Pointers / Near

Technical discussions related to Analog Devices DSPs (including Blackfin, TigerSHARC, SHARC and ADSP-21xx DSPs).

  

Post a new Thread

AW: Far Pointers / Near - Bernhard Holzmayer - Jul 23 6:10:00 2004



> -----Ursprüngliche Nachricht-----
> Von: duhlynn [SMTP:]
> Gesendet am: Donnerstag, 22. Juli 2004 16:43
> An:
> Betreff: [adsp] Far Pointers / Near
>
> Why does the ADSP219x C++ compiler require a overloading of the '='
> operator when using far qualified structures???
>
> The answer I got from ADI back in April:
> "The far keyword is treated as being a
> type qualifier like volatile. An explicit assignment operator is
> required for both far and volatile."
>
> Does anyone have a link to standards documentation on this?

The official ISO standard documentation isn't available without fee.
There's a news group at comp.lang.c++ where such stuff is regularly
discussed with fair competence,
you might post your question there.

As far as I can see, ADI's response is correct.

IMHO, it might help to understand the issue, if you consider this:

typedef int t_int;

The resulting type t_int is certainly congruent to the builtin type int,
however you'll certainly get warnings or even errors if you pick the wrong
one.
And this is the case not only with C++ but even with newer C compilers.
They should all mock if you use the wrong type.

This is even more important if you want to mix 'int' with 'volatile int'.
I like it if the compiler warns me if I unattendedly store a volatile value
into a non-volatile.
It happened very often that I just forgot about the volatile nature of the
underlying variable (especially if dealing with old code).
When the compiler issued a warning/error, it reminded me to check very
carefully if the right thing happens.

Another thing with pointers into different memory segments:
far pointers might be handled different from near pointers. I remember a
compiler which had one-byte pointers with very effective coding,
while far pointers were two-bytes wide and part of it consisted of a memory
type identifier and coding were less effective.
Therefore the compiler must know which type is on either side of an
assignment, and in neither case it could produce a single code for all
types and being well-optimized at the same time.

Guess it's not a big issue to redefine/overload the operator= and/or some
others.
If you want to create a base class which shall "export" the operator=
(which is not possible), it might export a function which does the work.
Then you need only call this function in the operator= definition.

If it's not mixing of different types of variables which you intend, but
only one code instance for all types:
did you try to solve this with templates?

Bernhard





(You need to be a member of adsp -- send a blank email to adsp-subscribe@yahoogroups.com )