Simple Question on Inline ASM

[newtheogott]

Coming back after long time not using Purebasic, I must say that the Editor has made a significant developement.
The compiler was also improved, and especially i like that its available in 32 and 64 bit.

In the compiler, i am missing primarily a second pass (i still have to declare things before using them - is that really state of the art 2009?), and i don't understand why there is no GOSUB / RETURN inside of Procedures.

Just trying to get it done with the Inline ASM like this:

Code: Select all

 Procedure hey()
    
    a.l = 1
  CALL l_asm_0001
    Debug a 
    
    Goto over 
         
    asm_0001: 
   ; a+10
   a=a+10
    RET 
    over:
    
    Debug a
  EndProcedure

hey()

Now i wonder that the compiler did not increase the "a" by 10 this way.
What i am missing here?

[Rings]

very simple,
normaly variables are hold on ths stack in procedures,
and ther stack varies if there is a gosub-return (Call and RET in asm).
So declare your variable as STATIC (STATIC a.l )=and it will not been on the stack.
and increase with 10 .

if i'm wrong fred, feel free to correct me.

[newtheogott]

Thanks for the Info. In the result, you are right. If i declare the variable as STATIC, it works.

a=11

But then this means, there is still no chance of having a "GOSUB" inside Procedures.

Because down there all variables will not work, or even do strange things, until i have returned from the "CALL".

What if i try to access Purebasic variables inside a INLINE-ASM Code where i have been using a CALL instuction? Then it just won't work, if i see this right. This would mean that this is actually not supported.

Is there a supported workaround, maybe to save the stack somewhere, access all variables and restore it before the RET?

[Fred]

There is no gosub in procedure for this very reason: variable are on the stack an there is no reliable way to find out there position as PB use direct stack indexing to save a register. That said, is gosub really a must-have (in 2009) ?

[Psychophanta]

You might find interesting this old thread:
http://www.purebasic.fr/english/viewtop ... f=3&t=8502

By the way, i wonder how did Mark Sibly do for Blitz Basic in amiga. There worked any call from inside a function: Inside to inside, inside to outside and viceversa. I guess that he didn't use the standard stack but another stack.

[newtheogott]

said, is gosub really a must-have (in 2009) ?

Fred, let me say first that after long time I like to see the good developments Purebasic made since i visited it last.
About the GOSUB, there are few cases where its just faster if you can use it, because it does not use the Stack-Frame a Procedure call with Parameters makes.
As its by Design not supported from Purebasic, the discussion on this topic is worthless.

So lets talk about the alternatives. MACROS could be taken as an alternative.
When trying the Macros, i realized that they actually seem not to support "Macro Local Labels" and Macro local Variables.

Code: Select all

MACRO Test()
MyLabel:

IF (a=b)
  GOTO MyLabel
endif
ENDMACRO

Using this MACRO, i could only use it ONCE because it contains a Label, that has to be unique.
Labels are in Purebasic not even Procedure-Local but Global, if my Tests were right.
I'd prefer Labels to be generally Procedure-local, as I would never want to Jump from outside into a Procedure.
Therefore I do not need the Label outside. But i could take the same Label in man Procedures.
In big Projects, i find myself making Lables like that: Label_0002 to avoid Duplicates.

So about this my wishlist for Purebasic contains here (not the GSUB as it seem unpossible) but these points:
- procedure-local labels (I don't know if this is possible)
- macro - local labels and variables (this one is easy to realize, just add a number in the preprocessor, each time the macro is called)
could use a #MACROTEMP a,b,d ; Directive

I'll make some more suggestions from my standpoint in another post.

[citystate]

rather than using a Macro to simulate GOSUB, why don't you just use a procedure with shared variables? wouldn't the functionality be simulated in this way?

[Foz]

That said, is gosub really a must-have (in 2009) ?

Code: Select all

1954 GOSUB 2009
...
2009 RETURN : REM --- Panic! Should not be here!

[Thorium]

rather than using a Macro to simulate GOSUB, why don't you just use a procedure with shared variables? wouldn't the functionality be simulated in this way?

No. He want this feature for speed optimization. The procedure call is much slower than a macro, even if you use shared variables. However a gosub would be a Call and calls are also slow. Using macros would be the best.

[citystate]

So lets talk about the alternatives. MACROS could be taken as an alternative.
When trying the Macros, i realized that they actually seem not to support "Macro Local Labels" and Macro local Variables.

Code: Select all

MACRO Test()
MyLabel:

IF (a=b)
  GOTO MyLabel
endif
ENDMACRO

Using this MACRO, i could only use it ONCE because it contains a Label, that has to be unique.

could you do something like this instead?

Code: Select all

MACRO Test(num)
Mylabel#num:
IF (a=b)
  GOTO MyLabel#num
endif
ENDMACRO

[blueznl]

I would like to see an example where Gosub is an essential. Could you give one? This is interesting to me, as I cannot think of one where it would matter

[Fred]

I never use Gosub, so i don't think it's essential. Now, that's a matter a coding, and we all respect that .

[freak]

I never use Gosub, so i don't think it's essential. Now, that's a matter a coding, and we all respect that .

The DocMaker source still has a few Gosub and it was written by you
They are not essential though... We're just too lazy to change it.

rather than using a Macro to simulate GOSUB, why don't you just use a procedure with shared variables? wouldn't the functionality be simulated in this way?

No. He want this feature for speed optimization. The procedure call is much slower than a macro, even if you use shared variables. However a gosub would be a Call and calls are also slow. Using macros would be the best.

This is not necessarily true. By blowing up the code size with macros you can easily make the code slower due to caching effects. Calls have become really cheap in today's CPUs (because of branch prediction with call-return stacks etc). So worrying about this kind of thing is a waste of time and even dangerous. Write your code, benchmark it and then you can start thinking about these kinds of optimizations if you really need them (chances are you won't).

About the GOSUB, there are few cases where its just faster if you can use it, because it does not use the Stack-Frame a Procedure call with Parameters makes.

A call to a procedure with no arguments is the exact same thing as a Gosub. Both just push a return address and jump to the target location. There are only further stack operations if the procedure has local variables (which Gosub does not have of course).

[newtheogott]

A call to a procedure with no arguments is the exact same thing as a Gosub. Both just push a return address and jump to the target location. There are only further stack operations if the procedure has local variables (which Gosub does not have of course).

I think this is the best sollution. As this is by-Design the way it shall be done in Purebasic any discussion does not make sense.
As said in other systems the use of GOSUB makes sense to me. In Purebasic I'll use PROCEDURES as structure-element in these cases and give the needed variables as parameter (BYREF).
Now I'll have to take a look how to give Parameters BYREF (by Reference) and BYVAL. How that works in Purebasic.

[citystate]

glad I could help