It's high time Delphi got it's own bytecode compiler. Here is a brief overview of the LDEF assembler. This was prototyped in Smart Mobile Studio and the code is what people call "ASM.JS" -- but I am porting over both the assembler, disassembler and runtime system to Delphi. Which means the bytecode system will be available on pretty much every platform known to mankind.
It's high time Delphi got it's own bytecode compiler. Here is a brief overview of the LDEF assembler. This was prototyped in Smart Mobile Studio and the code is what people call "ASM.JS" -- but I am porting over both the assembler, disassembler and runtime system to Delphi. Which means the bytecode system will be available on pretty much every platform known to mankind.
With the assembler in place, the next step is the high-level parser that takes your Delphi code and emits LDEF assembly. If I have my way you will be able to write bytecode based libraries that are platform independent next xmas.
Note: This project is not sanctioned by Embarcadero, this is purely my own research.
Delphi -> LLVM -> WASM ... profit
ReplyDeleteTo clarify: will your bytecode be WebAssebly-compatible, or is it your own bytecode that requires its own interpreter?
ReplyDeleteT n T Webassembly is still in its infancy and only suitable for computational operations. It has no access to the DOM, severe limitations on memory access and so on. This is "asm.js" which has none of those restrictions and runs at close to native speed. Things like Quake.js is asm-js. WebAssembly still needs 4-5 years before it becomes a viable option.
ReplyDeleteLike the video states, this is a complete runtime system, meaning its not webassembly. Its asm.js (google EmScripten for the C/C++ implementation on the same theme).
T n T Having said that, you might notice that my engine is register based. The reason for this is obvious: to make 1:1 conversion to other formats possible. The reason compiling dot-net and java to "real" machine code has been so hard, is because their engines are purely stack based. That is much harder to re-implement for a cpu, because cpu's are register based. So I wanted to have registers as the foundation straight away.
ReplyDeletehacks.mozilla.org - Why WebAssembly is Faster Than asm.js – Mozilla Hacks - the Web developer blog
ReplyDeleteRenaud GHIA Ofcourse webassembly is faster, but so what? Without access to the dom you will be pushing stack-frames and do context switching so much you will bleed cpu cycles (!). Webassembly is fun, but the cost within a web application is so high most developers opt for asm.js. Besides, nobody is forcing you to use this. Its the same thing all over .. the spin doctors do their thing and people lose their heads. Webassembly will be great for raw calculations, but try using it in a normal, desktop-like application and you will be sorely disappointed. Asm.js will rock for at least a decade. The W3C is like the vatican, they think in centuries, not years like normal human beings.
ReplyDeleteLDEF is a language building framework. Dont like it, pick something else :)
Willo van der Merwe Webasm is not a magic pill. Remember, all webasm runs isolated with NO access to the dom. It has more restrictions than webworkers and is nothing like people think. It would require a complete re-implementation of the RTL with only minor gains. Want object pascal for web - get Smart Mobile Studio
ReplyDeleteLennart Aasenden I was actually referring to implementing an LLVM compiler. That would allow output to various final stages even WASM.
ReplyDeleteDespite WASM not having access to the DOM, and, as far as I understand, there are no plans on giving it access either, it is still a great way to share common logic and classes between your back-end and front-end and AMAZING at number crunching.