Public labels!

[srod]

Hi,

Is there any way to label a procedure or data in such a way that it is not made public to other .obj's being linked, i.e. it remains strictly private to the .obj within which it is located?

I am working on a large project in which GoAsm is being used to create a lot of .obj's, not all of which will be written by myself, and there is of course a danger of duplicating names.  It will be difficult to avoid under certain conditions.

If this is not possible through some GoAsm directive, then how about my arranging for all 'internal' procedures to be bunched together within one 'frame' (not a GoAsm stack frame) and label them with reusable unscoped labels? I can then call them with long jumps.  The question I then need to ask is whether you can actually call such a label with the 'call' command?

If not, is it possible to use the $ counter along the following lines:

Code Select Expand


...blah blah main code

PUSH $+10                         ;+10 to get the address of the instruction XOR EAX, EAX ? This is the return address.
JMP LONG > p200
XOR EAX, EAX
...blah blah

etc.

;Now the 'internal' procedure.
p200:
;do some work.
;...blah blah
RET                                 ;Hoping this will return to the address pushed on the stack above.



I don't know, is something like this possible? 

Thanks in advance.

Stephen.

[jorgon]

Hi Stephen

One way to achieve this is in your calls to executable code is to use a reusable unscoped label (which is, by definition not "public"), but to make sure that the label is declared earlier in the source script and is in the same section.  If you do this, GoAsm itself will find the label and complete the call correctly.  The linker is not involved at all.

For example:-

Code Select Expand


CODE
;
p200:
          ;code goes here
RET
;
START:
CALL p200
RET
;


Since the CALL always codes "long" it does not matter that p200 is more than 128 bytes away.

For data, you can use data arrays for example:-

Code Select Expand


DATA
;
DATAp200
       DD 0        ;+0 chew
       DD 0        ;+4 fat
       DD 0        ;+8 swallow
       DD 0        ;+C sick
;
CODE
;
FATPROC:
MOV EAX,[DATAp200+4]             ;get fat into eax
CMP EAX,[DATAp200+8]             ;see if it has been swallowed
JZ >L1                           ;yes, too late
MOV ESI,[DATAp200+0Ch]           ;no, so sick it up into esi
L1:
RET


This produces only one unique label DATAp200.

Sorry, our cat keeps being sick.

[srod]

Nice one, thanks. I was hoping to be able to use an unscoped label in such a way, but wasn't sure - great!

A quick test and I see that an error ensues when making a forward call to an unscoped label using 'call'.  Makes sense!

Thanks Jeremy.  :U

[srod]

Right, we've solved the problem with keeping procedures private to individual .obj's.

Data?

Are there any issues with adapting your code above to the following:

Code Select Expand

DATA
;
DATAp200
       DD 0        ;+0 chew
       DD 0        ;+4 fat
       DD 0        ;+8 swallow
       DD 0        ;+C sick
;

#DEFINE fat DATAp200 + 4

CODE
;
FATPROC:
MOV EAX,[fat]             ;get fat into eax
...etc
RET


Using #DEFINE this way certainly seems to work okay. Am I correct in saying that such a definition does not make it's way into the .obj file - that is the definition of 'fat' is strictly private?  Probably a stupid question I know, but this will solve all my problems at the moment!  :wink

[jorgon]

It does work, "fat" is private, and also you can have

Code Select Expand


MOV EAX,ADDR fat


Stephen, I think you may start a new trend!

[srod]

Stephen, I think you may start a new trend!

:bg