Porting source code from C51 to ARMC

Mike - note that the Cortex do have bitbanding support - an aliased memory region where each 32-bit integer corresponds to one bit of a GPIO or registers. So you can write and read an integer and actually write or read a single bit. It's a feature of the memory controller of the processor, so it can be done with zero language extensions. But ARM did include language extensions just to "help out".

Mike - note that the Cortex do have bitbanding support - an aliased memory region where each 32-bit integer corresponds to one bit of a GPIO or registers. So you can write and read an integer and actually write or read a single bit. It's a feature of the memory controller of the processor, so it can be done with zero language extensions. But ARM did include language extensions just to "help out".

But ARM did include language extensions just to "help out".

Yes, but the bit type of the C51 is something completely different.

It is, but you can still write programs that looks like you have bit variables using the Cortex memory controller extensions. That you have a struct of 32-bit integers representing the individual bits doesn't really matter when you can write P0.pin3 = 1 without the compiler having to perform and/or operations hidden in the background. Or you can declare your gpio0_pin3 if you don't want to use a struct. So in the end, you do get very close to the bit variables of Keil C51.

Thanks "Mike" and "Per" for all your suggestions and comments. Sorry for being so brief in the original post, below I will go into a little more detail.

Regarding the Bit type of the C51, I completely agree with "Per" that a structure of 32 bit integers is perfectly acceptable, and in my case (porting from C51 to ARMC) functionally identical/equivalent.

For all those coming from the same direction as I, perhaps a little refresher is in order, namely:

In C51 bit variables are declared as such:

bit bdata Genbit0; // Bit 0
bit bdata Genbit1; // Bit 1

In ARMC (with bit banding), this may be done in the following manner:

typedef struct
{ uint8_t Genbit0 : 1; // Bit 0 uint8_t Genbit1 : 1; // Bit 1 . . . uint8_t Genbit31 : 1; // Bit 31
} GPBB

GPBB bb __attribute__((at(0x20000000))); // declare the variable the start of the SRAM Area

In a function setting or clearing a bit is simply done in this manner:
void foo (void)
{ bb.Genbit0 = 1; //Set the bit bb.Genbit1 = 0; //Clear the bit

}

In C51 indirectly addressed and External RAM variables are declared as such:

 char idata byte_var1;   // var 1
char idata byte_Var2;   // var 2

int xdata word_1;   // integer 1
int xdata word_2;   // integer 2

In ARMC this is done in the following manner:

 static int8_t byte_var1;   // byte_var1
static int8_t byte_var2;   // byte_var2

static int16_t word_1;   // integer 1
static int16_t word_2;   // integer 2

However here (in ARMC) you have no direct control of memory area, all variables go into RAM.

Finally in C51 declaring and locating variables is code is done in this manner:

 char code VersionInfo[] = "VERSION: 1.0.0";

Attempting to declare and locate in ARMC in this manner:

 const uint8_t VersionInfo[] = "VERSION: 1.0.0";

Looking at the MAP file I find the following to support my conclusions:

      .
      .
    sqrt                        0x0000e989   Thumb Code    76  sqrt.o(i.sqrt)
    VersionInfo                 0x0000e9d4   Data          15  main.o(.constdata)
      .
      .

That is, I expected (and intended) that "VersionInfo" be in the Thumb Code area (as it was in C51 code).

Any suggestions will be appreciated!

Regarding the Bit type of the C51, I completely agree with "Per" that a structure of 32 bit integers is perfectly acceptable, and in my case (porting from C51 to ARMC) functionally identical/equivalent.

I believe replacing bit with bool should be functionally identical, and simpler, and within the realm of standard C (C99 at least.)

As for idata and xdata, just drop these (as you did.) They don't make sense on an ARM, and they will do you no good.

As for code, replacing it with const is correct.