re-entrant? code variables

re-entrant? code variables

Post by Spider plant breeding progra » Thu, 19 Jun 1997 04:00:00

OS_ReadVarVal is re-entrant. (IIRC)

I don't remember anything about the code for code variables needing to be

Does OS_ReadVarVal take precautions not to try to read the same code
variable, or should all code variable code be re-entrant?
(and hence there is a documentation omission)

#!perl    # Save this to a file *before* running it
BEGIN{use Socket;$_='YIN;$|=sockef,PZSOCK_STREAM,~proto"tcp"and connecf,pack
"Sna4x8",AZ79,(~host$^I)[4]or die$!YOUT;prinf"/w nickc\r";print"[$^I]"';s/Y/
;select STD/g;s/f/t STDIN/g;s/Z/F_INET,/g;s/~(\w*)/get$1byname/g;eval||die}


1. Re-entrant code obtaining addresses

Hello folks,

In a re-entrantly compiled C function, what code is generated to access
various functions and data, in the same 'link unit' (say, a .o file) and
in others?  What would Norcroft generate?  Should other compiler's
generate the same code (if they could)?  Is it a matter of compiler
options (other than re-entrancy)?

I take it that a group of functions in the same link unit would expect
sb to point to a block of data for objects with static storage duration
defined in the same link unit, so to access a 1-word object:

LDR     rx,[sb,#sb_offset]   ; load the object's value into rx
ADD     rx,sb,#sb_offset     ; load the object's address into rx

i.e. just use an offset determined at link time?

If the data is completely constant and so doesn't need to appear
separately in the static block, I suppose it could be relative to the
code, so:

LDR     rx,[pc,#pc_offset]   ; load the object's value into rx
ADD     rx,pc,#pc_offset     ; load the object's address into rx

To access an external object, would one assume that its address has
previously been stored at a particular offset from sb, as if:

   extern int their_data;

   int func(void) { return their_data; }

was compiled as:

   extern int *their_data_ptr = &their_data;

   int func(void) { return *their_data_ptr; }


To call a function in the same link unit, one could presumably just BL
to it as normal (perhaps setting ip=sb first, or avoiding part of the
entry sequence that sets sb from ip)...?

What about a function with a different sb?  Would one assume that the
static data had been set up to contain its address?  For example:

MOV     lr,pc
LDR     pc,[sb,#sb_offset]

Would one assume that the address was really a veneer that set up ip, or
expect that to be stored in the static block as well?  For example:

LDR     ip,[sb,#sb_offset+4]
MOV     lr,pc
LDR     pc,[sb,#sb_offset]

These would imply either 4- or 8-byte functions pointers, right?

If one wanted to export the address of some local function requiring sb,
would one of these be used:

ADD     rx,pc,#pc_offset    ; 8-byte function pointer
MOV     ry,sb


LDR     rx,[sb,#sb_offset]  ; 4-byte function pointer

i.e. the static block includes a pointer to the local function's veneer,
right?  Or maybe the veneer could be in the static block?

What would be suitable code for a veneer?:

MOV     ip,pc
LDMIA   ip,{ip,pc}
DCD     new_sb_value
DCD     new_pc_value

 From which end of my alimentary canal am I talking?

Please be gentle - it's a while since I wrote any ARM code in anger.



2. ErrorCode 29

3. Allocating static's in re-entrant modules

4. Speed control of DC Motor

5. Code variables R12

6. need input

7. Code variables

8. ADV: gInstall: Red Army Day Price crash!

9. Duke Nukem Cheat Codes, and Future Shock (Terminator) codes!

10. ARM code game engine - is this code ok ?

11. Atmel ARM code to (Gnu) arm-unknown-elf-as code?

12. Acorn Code : Geek Code supplement for us Acorn users!