PureBasic Forums - English

Another option might be to create a simple byte code interpreter.
It's not as fast as machine-code of course but would allow for flexibility.

DoctorLove wrote:Well, im doing it all with http://www.oxygenbasic.org/

Its a simple DLL which compiles and execute basic code on the fly.
The language is Mature and basic to learn.

MAC osx and Linux are in the making.

Im sold to it.

That really looks awesome, nice clear syntax, I'm going to look into that more!
However, considering this is a compiler, does it also include the possibility to
assemble its supported code to a buffer that can be executed like with the
fASM dll does above? I bookmarked it, interesting, thanks!

edit
Yes a byte-code interpreter might be an option, however if I'd (for example) were
to extend Lua with a function that allows for allocation and execution of blocks of
assembly code (machine code), that would be cool because Lua is already an
interpreted language that precompiles to bytecode.

Bytecode would mean I'd have to develop an engine with fixed functionality, fASM
provides me with an option to simply execute code without having to develop
additional stuff. The Lua and does the work before the assembly is made, e.g. obtain
a pointer to a function and do some nice stuff with it.

wilbert wrote:Another option might be to create a simple byte code interpreter.
It's not as fast as machine-code of course but would allow for flexibility.

If it's used very dynamicly, the interpreter is actualy faster. Assembling strings to machine code is quite slow and would only result in a good performance if the code is generated once and executed many times unchanged.

Thorium wrote:

wilbert wrote:Another option might be to create a simple byte code interpreter.
It's not as fast as machine-code of course but would allow for flexibility.

If it's used very dynamicly, the interpreter is actualy faster. Assembling strings to machine code is quite slow and would only result in a good performance if the code is generated once and executed many times unchanged.

That's what I was aiming at, compiling assembly code to a buffer and executing it multiple times as a registered cfunction in Lua.
Or even via a fastcall.

I want the assembly part because I want users of scripting languages like Lua to be able to generate actual functions,
instead of just the interpreted functions in Lua.

Crusiatus Black wrote: I want the assembly part because I want users of scripting languages like Lua to be able to generate actual functions,
instead of just the interpreted functions in Lua.

You want inline ASM for LUA?
Interessting idea.

Thorium wrote:

Crusiatus Black wrote: I want the assembly part because I want users of scripting languages like Lua to be able to generate actual functions,
instead of just the interpreted functions in Lua.

You want inline ASM for LUA?
Interessting idea.

Yeah, I've already managed to build a module specifically for Autoplay Media Studio (using Lua 5.1), and the assembling
and execution of the code works amazing. I think that this could be easily ported to a Lua module adding a simple
function (e.g. asm(str)) for other Lua engines.

The function in the module returns a table with the metamethod __call calling the assembled code, passing on all the
arguments the function receives.

Inline assembly in Lua, this is really something I like.

Thorium wrote:

wilbert wrote:Another option might be to create a simple byte code interpreter.
It's not as fast as machine-code of course but would allow for flexibility.

If it's used very dynamicly, the interpreter is actualy faster. Assembling strings to machine code is quite slow and would only result in a good performance if the code is generated once and executed many times unchanged.

Many heavy-lifting JIT implementations will do both, only taking the time to create an optimized assembly for a span of code if it gets executed multiple times.

I might end up going that route eventually for my own project, but for the near term a threaded code interpreter does the job just fine. It's faster than many people think, and very easy to debug.

Those are the opcodes, 0x68 in these examples is the PUSH instruction. I found those values in
other examples doing this thing online.

It was only me experimenting with creating executable buffers real-time, and creating procedures
real-time. In the end I solved it using the FASM dll assembling actual assembly code to a VM buffer.

Result: The ASM module in MemoryEx and the assemblies section in IMXLH at http://www.memoryex.net/,
which is why I originally was experimenting with this stuff.