HIWAVE object format causes C12005 non default function pointer

HIWAVE object format causes C12005 non default function pointer

Post by codewarr20 » Sat, 15 May 2004 05:21:06


Using the MC68HC9S12DP256 CPU bean.
Chc12.exe version 5.0.23 build 3249
linker.exe version 5.0.21 build 3249

I am using banked memory model with PPAGE=RUNTIME

I want to be able to locate CONSTANTs in seperate memory banks instead
of NON_BANKED_ROM and from what I have read in the Compiler manual for
command line option -Cc that this is only possible with the HIWAVE
file format.

I selected the
-Fh compiler generate option - HIWAVE object file format
-Fa linker input option - auto detect object format

I am getting error c12005 non default function pointer are not
supported in HIWAVE object file format.

In: Vectors.c on this line:

--> typedef void (*near tIsrFunc)(void);
const tIsrFunc _vect[] @0xFF80 = { /* Interrupt table */
Cpu_Interrupt, /* 0 Default (unused)
interrupt */

What needs to be changed?
** This file was created by UNIS Processor Expert 03.33 for
** the Motorola HCS12 series of microcontrollers.

Since this is auto generated, what do I do. I really need this
interrupt table/structure.

Thanks, T.
 
 
 

HIWAVE object format causes C12005 non default function pointer

Post by Daniel Fri » Sat, 15 May 2004 06:52:02

Hi,

see below,



The compiler option -Cc is needed in the HIWARE format to get constants into ROM (if constants are not
explicitly put into a section which is placed in ROM).
In ELF constants in the DEFAULT section do go automatically into ROM.
That's why the -cc option only has an effect int he HIWARE format: Its effect is the default in ELF.


Use the HIWARE format if your de *** is only supporting this object file format. Otherwise choose ELF/DWARF 2.0, the default one.


That's the default anyway.


You could use a "void*__near" data pointer instead of a function pointer, but I'm not sure how to
change this in an automatically generated PE file.
But really, I would suggest to switch back to ELF.
In the HIWARE format, the linker is responsible for global initializations like for this _vect array.
And the linker does currently not support non default function pointers (again: in the hiware format).


Use ELF :-).



To actually make the compiler generate far accesses here a little example for you.

#include "termio.h"

#pragma CONST_SEG __PPAGE_SEG MY_PPAGE_SEGNAME
const char FarConst[]= "Hello Far World\n";
#pragma CONST_SEG DEFAULT

void main(void) {
TERMIO_Init();
for (;;) {
const char* __far ptr= FarConst;
char c;
do {
c= *ptr;
TERMIO_PutChar(c);
ptr++;
} while (c != 0);
}
}

Then place the MY_PPAGE_SEGNAME section in some paged segment in the prm

Note that the far accesses using the runtime routine are rather slow and generate significantly more code than extended variables.
So consider if it is not possible for your application to keep the constants together with their accessing function on the same page.
If possible, try to reduce the code handling with the far data.

Bye

Daniel

 
 
 

HIWAVE object format causes C12005 non default function pointer

Post by Daniel Fri » Sat, 15 May 2004 06:53:38

Hi,

see below,



The compiler option -Cc is needed in the HIWARE format to get constants into ROM (if constants are not
explicitly put into a section which is placed in ROM).
In ELF constants in the DEFAULT section do go automatically into ROM.
That's why the -cc option only has an effect int he HIWARE format: It's effect is the default in ELF.


Use the HIWARE format if your de *** is only supporting this object file format. Otherwise choose ELF/DWARF 2.0.


That's the default anyway.


You could use a "void*__near" data pointer instead of a function pointer, but I'm not sure how to
change this in an automatically generated PE file.
But really I would suggest to switch back to ELF.
In the HIWARE format, the linker is responsible for global initializations like for this _vect array.
And the linker does currently not support non default function pointers (again: in the hiware format).


Use ELF :-).



To actually make the compiler generate far accesses here a little example for you.

#include "termio.h"

#pragma CONST_SEG __PPAGE_SEG MY_PPAGE_SEGNAME
const char FarConst[]= "Hello Far World\n";
#pragma CONST_SEG DEFAULT

void main(void) {
TERMIO_Init();
for (;;) {
const char* __far ptr= FarConst;
char c;
do {
c= *ptr;
TERMIO_PutChar(c);
ptr++;
} while (c != 0);
}
}

Then place the MY_PPAGE_SEGNAME section in some paged segment in the prm

Note that the far accesses using the runtime routine are rather slow and generate significantly more code than extended variables.
So consider if it is not possible for your application to keep the constants together with their accessing function on the same page.
If possible, try to reduce the code handling with the far data.

Bye

Daniel
 
 
 

HIWAVE object format causes C12005 non default function pointer

Post by Daniel Fri » Sat, 15 May 2004 06:55:12

Hi,

see below,



The compiler option -Cc is needed in the HIWARE format to get constants into ROM (if constants are not
explicitly put into a section which is placed in ROM).
In ELF constants in the DEFAULT section do go automatically into ROM.
That's why the -cc option only has an effect int he HIWARE format: It's effect is the default in ELF.


Use the HIWARE format if your de *** is only supporting this object file format. Otherwise choose ELF/DWARF 2.0.


That's the default anyway.


You could use a "void*__near" data pointer instead of a function pointer, but I'm not sure how to
change this in an automatically generated PE file.
But really I would suggest to switch back to ELF.
In the HIWARE format, the linker is responsible for global initializations like for this _vect array.
And the linker does currently not support non default function pointers (again: in the hiware format).


Use ELF :-).



To actually make the compiler generate far accesses here a little example for you.

#include "termio.h"

#pragma CONST_SEG __PPAGE_SEG MY_PPAGE_SEGNAME
const char FarConst[]= "Hello Far World\n";
#pragma CONST_SEG DEFAULT

void main(void) {
TERMIO_Init();
for (;;) {
const char* __far ptr= FarConst;
char c;
do {
c= *ptr;
TERMIO_PutChar(c);
ptr++;
} while (c != 0);
}
}

Then place the MY_PPAGE_SEGNAME section in some paged segment in the prm

Note that the far accesses using the runtime routine are rather slow and generate significantly more code than extended variables.
So consider if it is not possible for your application to keep the constants together with their accessing function on the same page.
If possible, try to reduce the code handling with the far data.

Bye

Daniel
 
 
 

HIWAVE object format causes C12005 non default function pointer

Post by codewarr20 » Sat, 15 May 2004 21:47:50

aniel Friederich < XXXX@XXXXX.COM > wrote in message news:< XXXX@XXXXX.COM >...
Ok, so the documentation on the -Cc is a little weak then. One can
place CONSTANTS in PPAGE segments where they would be local to the
pragmaed code at the same PPAGE segment. Correct?

So for the -CpPPAGE=RUNTIME should I use -CpPPAGE=0x3E if I am only
using PPAGE and not implementing EPAGE and DPAGE?

I am assuming extended variables means far variables?


Thanks, Daniel. T.
 
 
 

HIWAVE object format causes C12005 non default function pointer

Post by Daniel Fri » Sun, 16 May 2004 02:09:22

> Ok, so the documentation on the -Cc is a little weak then. One can

One can. However for this to the functions and the constants have to be placed into specific sections and then these sections have to be
allocated explicitly in prm file.
If you guarantee that all variables are on the same page as all code accessing them,
you do not need (you should not) specify "PPAGE" in the #pragma CONST_SEG.
As soon as you specify it, the compiler will generate accesses which do set the PPAGE
(or which are performed with one of the runtime routine with -CpPPAGE=RUNTIME).

...

No. If you are not using EPAGE or DPAGE (which don't exist for the DP256 :-), then do not specify -CpEPAGE and -CpDPAGE.
Use "-CpPPAGE=RUNTIME" if your code and the constants are both in the PPAGE controlled areas and possibly on different pages.
Use "-CpPPAGE=0x30" (PPAGE is at 0x30 and not at 0x3E, as far as I remember) if your code is NOT in the PPAGE controlled area from 0x8000 to 0xBFFF.
So this last setup makes sense if you really have a lot of constants but your code does still fit into the non banked areas.



No. With extended I was referring to the Extended Addressing Mode, basically variables accessed with 16 bit addressing.