Allow BlitzMax variables in native code

[woollybah]

Currently, native code (inline C) can't directly interact with BlitzMax code, because we don't have a way to refer to BlitzMax variables within the native statements.

We can't use variable as-is in the native code, because the actual generated variable names are different. So, for example, we can't do this :

SuperStrict
Framework BRL.Standardio

Local a:Int = 10

'! printf("a = %d\n", a);
Print "a = " + a

because a in the native section is an unknown variable.

We may be able to prefix the variable in the native code, parse it, and check it during the semanting phase. The @ symbol seems a reasonable choice as it is not used in C. So we could end up with something like :

SuperStrict
Framework BRL.Standardio

Local a:Int = 10

'! printf("a = %d\n", @a);
Print "a = " + a

where @a would be replaced by the correct variable name during generation.

[GWRon]

What about "var" ? What happens if I intend to pass something as "reference" (aka "var") ? I could surely circument it by something like

'! @a = manipulate(@a)

But how do it without relying on the return value?

Also: for now the C-Standard does not use @, ok. But what happens if it becomes used in a later standard?

[woollybah]

Inlining C is an advanced feature. If you want to abuse it, that's completely up to you. You can also abuse normal BlitzMax variables too, if that's your thing...

[HurryStarfish]

Most of the time, the C name is just the BlitzMax name with bbt_ added at the start, so it's already quite easy to access BlitzMax locals from native code. It does feel a bit dirty, but so does adding new symbols to the C code, imo. What if we had the option to control the name mangling like with top level functions? Maybe we could allow declaring Locals in an Extern or Export block (to expose C locals to BlitzMax or BlitzMax locals to C, respectively)?

[davecamp]

I know this is a late reply... but it's still open so I'll drop a cent,,,

If you use a constant name mangling scheme then you can use c macros to allow access to the BMax variables. You could emit a header(?) with the macro in it for the c code to include - just in case the name mangling changes in the future.

This would keep the c code clean and readable and also signify the intention of the c code for other readers.

Any thoughts?

[davecamp]

oh ! I think totally misunderstood what you want to do here? The title says about accessing BMax variables from native code... but then go on to include native code in the BMax source.

My reply was a suggestion to provide a method of accessing BMax varaibles from c code - not inlining c code in the BMax code.

[GWRon]

Yes it was about accessing blitzmax variables inside the "native code lines".

They are not precompiled as it happens with .c files but more like "include" (compared to blitzmax' "import")

[davecamp]

What advantages can be gained from in-lining c code (other than losing the possible overhead of setting up a stack frame, which may not happen when the c code is compiled with optimisations) ?

[GWRon]

You do not have to write an additional c file just to have a little "printf" output.

[davecamp]

Why not use Print in that case? There must be a bigger picture that I don't see at the mo :p

[GWRon]

Print does not use vargs... ;-) (For now bmx does not allow "unlimited" arguments...except by using an array param).

There might be even other commands available in the standard modules of C which aren't available in Blitzmax.

Most important reason is: you allow inlined c code...why not allow for a communication between bmx and inlined code. Or: why allow native code at all?

[davecamp]

I do remember coming across one situation where I wanted to call BMax code from c++ code years ago and that was so I could create complete usable COM objects that would have been created it the BMax language... which requires the COM system to call method in the COM objects. This meant method pointers which seemed were never going to exist.

Isn't it the case that most c code used with BMax will be library code designed 'to be called'? I guess sometimes libraries will want a callback function or similar which, admittedly, would require a little c code but is there anything else?

If the real issue is to allow variadic parameters/arguments then why not implement it properly in the compiler?

[davecamp]

Be careful not to lose sight of the original goal of what BlitzMax stands for... making 2D games across multiple platforms :-)

[GWRon]

The original issue came from a thread on syntaxbomb.com about a bug report (if you had an error in the native code it resulted in a maxide crash).

So for me personally there is no need for that feature. I would prefer a cross platform sdl compatible render 2 texture ;-)