#198 How to know the segment number of a label in banked Roms

[Ragozini Arturo]

In my project, I have a banked ROM with segments of 16KB each. The layout is the following

System Rom 16K 0000h-3FFFFh
Page 0 Rom 16K 4000h-7FFFh
Page 1 Rom 16K 8000h-BFFFh
System RAM 16K C000h-FFFFh

A mapper is in charge of swapping the segments in Page 0 and Page 1 (4096KB of rom in 64 segments).
I need to include in the rom a data structure larger that 16KB (thus spanning on more than one segment).

I need to put in RAM an array of pointers to the records in the data structure, holding both the address and the segment number of the specific record.

From what I can see, the SDCC manual does not include any mean to return the segment of a specific array or label.... Is there a way, maybe in ASM, to include in a data structure the segment number of a specific label ?

In order to make things more clear, in attach there is the file with the data I would arrange as above.

The data that have to stay in rom spanning on multiple segments are those bloks:

// frame # 0     Nspr = 12 
const unsigned char  FrmNs0  = 12;    // # sprites in this frame 
const unsigned char  Frmdx0[]  = {0xEA,0xEA,0xEA,0xEA,0xFA,0xFA,0xFA,0xFA,0x0A,0x0A,0x0A,0x0A,};       // dx
const unsigned char  Frmdy0[]  = {0xF3,0xF3,0x03,0x03,0xF3,0xF3,0x03,0x03,0xF3,0xF3,0x03,0x03,};       // dy
const unsigned int   FrmPat0[] = {0x0510,0x04B0,0x2F20,0x4460,0x2A40,0x1690,0x6250,0x6510,0x1480,0x10F0,0x3400,0x6490,}; // pat addresses (x2!)
const unsigned int   FrmCol0[] = {0x0280,0x01B0,0x3430,0x3550,0x2640,0x18E0,0x2500,0x47D0,0x0750,0x0590,0x3460,0x34F0,}; // col offsets
.....

The array of pointers that have to stay in ram including the segment number of each pointer is the following:

unsigned char*  FrameAddr[] = {
  &FrmNs0,&FrmNs1,&FrmNs2,&FrmNs3,&FrmNs4,&FrmNs5,&FrmNs6,&FrmNs7,&FrmNs8,&FrmNs9,&FrmNs10,&FrmNs11,&FrmNs12,&FrmNs13,&FrmNs14,&FrmNs15,&FrmNs16,&FrmNs17,&FrmNs18,&FrmNs19,&FrmNs20,&FrmNs21,&FrmNs22,&FrmNs23,&FrmNs24,&FrmNs25,&FrmNs26,&FrmNs27,&FrmNs28,&FrmNs29,&FrmNs30,&FrmNs31,&FrmNs32,&FrmNs33,&FrmNs34,&FrmNs35,&FrmNs36,&FrmNs37,&FrmNs38,&FrmNs39,&FrmNs40,&FrmNs41,&FrmNs42,&FrmNs43,&FrmNs44,&FrmNs45,&FrmNs46,&FrmNs47,&FrmNs48,&FrmNs49,&FrmNs50,&FrmNs51,&FrmNs52,&FrmNs53,&FrmNs54,&FrmNs55,&FrmNs56,&FrmNs57,&FrmNs58,&FrmNs59,&FrmNs60,&FrmNs61,&FrmNs62,&FrmNs63,&FrmNs64,&FrmNs65,&FrmNs66,&FrmNs67,&FrmNs68,&FrmNs69,&FrmNs70,&FrmNs71,&FrmNs72,&FrmNs73,&FrmNs74,&FrmNs75,&FrmNs76,&FrmNs77,&FrmNs78,&FrmNs79,&FrmNs80,&FrmNs81,&FrmNs82,&FrmNs83,&FrmNs84,&FrmNs85,&FrmNs86,&FrmNs87,&FrmNs88,&FrmNs89,&FrmNs90,&FrmNs91,&FrmNs92,&FrmNs93,&FrmNs94,&FrmNs95,&FrmNs96,&FrmNs97,&FrmNs98,&FrmNs99,&FrmNs100,&FrmNs101,&FrmNs102,&FrmNs103,&FrmNs104,&FrmNs105,&FrmNs106,&FrmNs107,&FrmNs108,&FrmNs109,&FrmNs110,&FrmNs111,&FrmNs112,&FrmNs113,&FrmNs114,&FrmNs115,&FrmNs116,&FrmNs117,&FrmNs118,&FrmNs119,&FrmNs120,&FrmNs121,&FrmNs122,&FrmNs123,&FrmNs124,&FrmNs125,&FrmNs126,&FrmNs127,&FrmNs128,&FrmNs129,&FrmNs130,&FrmNs131,&FrmNs132,&FrmNs133,&FrmNs134,&FrmNs135,&FrmNs136,&FrmNs137,&FrmNs138,&FrmNs139,&FrmNs140,&FrmNs141,&FrmNs142,&FrmNs143,&FrmNs144,&FrmNs145,&FrmNs146,&FrmNs147,&FrmNs148,&FrmNs149,&FrmNs150,&FrmNs151,&FrmNs152,&FrmNs153,&FrmNs154,&FrmNs155,&FrmNs156,&FrmNs157,&FrmNs158,&FrmNs159,&FrmNs160,&FrmNs161,&FrmNs162,&FrmNs163,&FrmNs164,&FrmNs165,&FrmNs166,&FrmNs167,&FrmNs168,&FrmNs169,&FrmNs170,&FrmNs171,&FrmNs172,&FrmNs173,&FrmNs174,&FrmNs175,&FrmNs176,&FrmNs177,&FrmNs178,&FrmNs179,&FrmNs180,&FrmNs181,&FrmNs182,&FrmNs183,&FrmNs184,&FrmNs185,&FrmNs186,&FrmNs187,&FrmNs188,&FrmNs189,&FrmNs190,&FrmNs191,&FrmNs192,&FrmNs193,&FrmNs194,&FrmNs195,&FrmNs196,&FrmNs197,&FrmNs198,&FrmNs199,&FrmNs200,&FrmNs201,&FrmNs202,&FrmNs203,&FrmNs204,&FrmNs205,&FrmNs206,&FrmNs207,&FrmNs208,&FrmNs209,&FrmNs210,&FrmNs211,&FrmNs212,&FrmNs213,&FrmNs214,&FrmNs215,&FrmNs216,&FrmNs217,&FrmNs218,&FrmNs219,&FrmNs220,&FrmNs221,&FrmNs222,&FrmNs223,&FrmNs224,&FrmNs225,&FrmNs226,&FrmNs227,&FrmNs228,&FrmNs229,&FrmNs230,&FrmNs231,&FrmNs232,&FrmNs233,&FrmNs234,&FrmNs235,&FrmNs236,&FrmNs237,&FrmNs238,&FrmNs239,&FrmNs240,&FrmNs241,&FrmNs242,&FrmNs243,&FrmNs244,&FrmNs245,&FrmNs246,&FrmNs247,&FrmNs248,&FrmNs249,&FrmNs250,&FrmNs251,&FrmNs252,&FrmNs253,&FrmNs254,&FrmNs255,&FrmNs256,&FrmNs257,&FrmNs258,&FrmNs259,&FrmNs260,&FrmNs261,&FrmNs262,&FrmNs263,&FrmNs264,&FrmNs265,&FrmNs266,&FrmNs267,&FrmNs268,&FrmNs269,&FrmNs270,&FrmNs271,&FrmNs272,&FrmNs273,&FrmNs274,&FrmNs275,&FrmNs276,&FrmNs277,&FrmNs278,&FrmNs279,&FrmNs280,&FrmNs281,&FrmNs282,&FrmNs283,&FrmNs284,&FrmNs285,&FrmNs286,&FrmNs287,&FrmNs288,&FrmNs289,&FrmNs290,&FrmNs291,&FrmNs292,&FrmNs293,&FrmNs294,&FrmNs295,&FrmNs296,&FrmNs297,&FrmNs298,&FrmNs299,&FrmNs300,&FrmNs301,&FrmNs302,&FrmNs303,&FrmNs304,&FrmNs305,&FrmNs306,&FrmNs307,&FrmNs308,&FrmNs309,&FrmNs310,&FrmNs311,&FrmNs312,&FrmNs313,&FrmNs314,&FrmNs315,&FrmNs316,&FrmNs317,&FrmNs318,&FrmNs319,&FrmNs320,&FrmNs321,&FrmNs322,&FrmNs323,&FrmNs324,&FrmNs325,&FrmNs326,&FrmNs327,&FrmNs328,&FrmNs329,&FrmNs330,&FrmNs331,&FrmNs332,&FrmNs333,&FrmNs334,&FrmNs335,&FrmNs336,&FrmNs337,&FrmNs338,&FrmNs339,&FrmNs340,&FrmNs341,&FrmNs342,&FrmNs343,&FrmNs344,&FrmNs345,&FrmNs346,&FrmNs347,&FrmNs348,&FrmNs349,&FrmNs350,&FrmNs351,&FrmNs352,&FrmNs353,&FrmNs354,&FrmNs355,&FrmNs356,&FrmNs357,&FrmNs358,&FrmNs359,&FrmNs360,&FrmNs361,&FrmNs362,&FrmNs363,&FrmNs364,&FrmNs365,&FrmNs366,&FrmNs367,&FrmNs368,&FrmNs369,&FrmNs370,&FrmNs371,&FrmNs372,&FrmNs373,&FrmNs374,&FrmNs375,&FrmNs376,&FrmNs377,&FrmNs378,&FrmNs379,&FrmNs380,&FrmNs381,&FrmNs382,&FrmNs383,&FrmNs384,&FrmNs385,&FrmNs386,&FrmNs387,&FrmNs388,&FrmNs389,&FrmNs390,&FrmNs391,&FrmNs392,&FrmNs393,&FrmNs394,&FrmNs395,&FrmNs396,&FrmNs397,&FrmNs398,&FrmNs399,&FrmNs400,&FrmNs401,&FrmNs402,&FrmNs403,&FrmNs404,&FrmNs405,&FrmNs406,&FrmNs407,&FrmNs408,&FrmNs409,&FrmNs410,&FrmNs411,&FrmNs412,&FrmNs413,&FrmNs414,&FrmNs415,&FrmNs416,&FrmNs417,&FrmNs418,&FrmNs419,&FrmNs420,&FrmNs421,&FrmNs422,&FrmNs423,&FrmNs424,&FrmNs425,&FrmNs426,&FrmNs427,&FrmNs428,&FrmNs429,&FrmNs430,&FrmNs431,&FrmNs432,&FrmNs433,&FrmNs434,&FrmNs435,&FrmNs436,&FrmNs437,&FrmNs438,&FrmNs439,&FrmNs440,&FrmNs441,&FrmNs442,&FrmNs443,&FrmNs444,&FrmNs445,&FrmNs446,&FrmNs447,&FrmNs448,&FrmNs449,&FrmNs450,&FrmNs451,&FrmNs452,&FrmNs453,&FrmNs454,&FrmNs455,&FrmNs456,&FrmNs457,&FrmNs458,&FrmNs459,&FrmNs460,&FrmNs461,&FrmNs462,&FrmNs463,&FrmNs464,&FrmNs465,&FrmNs466,&FrmNs467,&FrmNs468,&FrmNs469,&FrmNs470,&FrmNs471,&FrmNs472,&FrmNs473,&FrmNs474,&FrmNs475,&FrmNs476,&FrmNs477,&FrmNs478,&FrmNs479,&FrmNs480,&FrmNs481,&FrmNs482,&FrmNs483,&FrmNs484,&FrmNs485,&FrmNs486,&FrmNs487,&FrmNs488,&FrmNs489,&FrmNs490,&FrmNs491,&FrmNs492,&FrmNs493,&FrmNs494,&FrmNs495,&FrmNs496,&FrmNs497,&FrmNs498,&FrmNs499,&FrmNs500,&FrmNs501,&FrmNs502,&FrmNs503,&FrmNs504,&FrmNs505,&FrmNs506,&FrmNs507,&FrmNs508,&FrmNs509,&FrmNs510,&FrmNs511,&FrmNs512,
}; // init data

[Ragozini Arturo]

For banked functions (using__banked), SDCC and its tool chain is generating in ASM b_NameFunction holding the number of the segment of the function.
I cannot see anything similar for data.

[Janko Stamenović]

Can you maybe explain why you'd need compiler support for that, compared to simply creating your array corresponding of the segments of the arrays you create? What's the use case? Would you really want to have bank switches happening automatically whenever you access a single element? Isn't it better to manage switches yourself so that it happens much less often?

[Ragozini Arturo]

My problem is that the data I'm generating are much bigger that a single segment and the code that is using the data should be able to to swap segment to access to any record randomly.
Having the segment number and the address of each record in an array (in ram or in ROM with the code using the data) would allow the processing I need.

[Janko Stamenović]

Edit: to reformulate question, what precisely do you think the compiler should do, instead of you simply creating an array of the bank layout of your structures and switching in your code the banks exactly when you want?

I can't imagine how an example of the resulting code you expect would look like?

Original: But you surely don't want to do switching before each byte access? If not, isn't it something that is better when you, as a programmer who knows what would be the best, plan, schedule and manage independently of the compiler?

[Ragozini Arturo]

No, I need to switch page when accessing to a record whose size can vary from 6 to about 120 bytes. But do not worry. I see that what I was looking for isn't available.

I will process my records in order to generate directly binary data in chunks of 16KB each and generate offsets and relative segment numbers to access to the data structures

[Ragozini Arturo]

Anyway, considering that for banked functions, SDCC and its tool chain is already able to generate an ASM symbol for the segment number b_FuncName, it could be very handy to introduce a similar mechanic for constants and constant arrays placed in banked roms.

The feature would be used mainly by ASM code that needs to refer to C data.