TwinBasic

[fafalone]

vbsedit is also used to write 64-bit game scripts, which would be more convenient if twinbasic could put assembly code directly into it. It runs several times faster

Well out of all that incoherent mess, I could at least find one thing I understood and definitely agree with

tB can't rival truly surpass VB in power until it has some mechanism to insert ASM, preferably inline, but at least linked in functions. Of course you can execute thunks in memory just like VB6, so long as you're not relying on VB6 internals that aren't replicated.

Since twinbasic must have the EDGE runtime installed first, the webview2 control should be displayed in the Controls toolbox by default, without requiring additional complex references to be added.

You've misunderstood what the WebView2 runtime is. It allows you to create e.g. a Browser control, but MS does not provide one itself. It's also not really a complex reference; it's one box to check in the references list, TWINPACK PACKAGES->WebView2 Package. That adds the basic implementation Wayne made. You want inline assembly but balk at needing to add a reference?

[Niya]

tB can't rival truly surpass VB in power until it has some mechanism to insert ASM, preferably inline, but at least linked in functions.

Great care must be taken with this because one of the stated goals of TwinBASIC is multiplatform targeting. Assuming this means to include targets like MAC and Android, hand-written assembly would reduce the portability of the code.

You could end up with situations where people release libraries that contain platform specific assembly and all hell would break loose when they try to compile it for another platform.

[PlausiblyDamp]

tB can't rival truly surpass VB in power until it has some mechanism to insert ASM, preferably inline, but at least linked in functions. Of course you can execute thunks in memory just like VB6, so long as you're not relying on VB6 internals that aren't replicated.

As well as what Niya said in https://www.vbforums.com/showthread....=1#post5607201

Also consider that there is a big difference between writing ASM code and writing optimised ASM code. Modern CPUs are very complex when you take into account things like caching, branch prediction, return address prediction, and that isn't taking into account the various SIMD instruction sets (SSE, AVX, AVX2, AVX-512 just on x64 alone).

It would be much better having a compiler that can generate correct, optimised assembler instead; if the compiler / runtime / framework / whatever can also expose platform neutral wrappers over lower level functionality then you can get the best of both worlds.

[Schmidt]

It would be much better having a compiler that can generate correct, optimised assembler instead...

+1

And in case TBs/Waynes intention, to finally use LLVM for (optimized) code-generation at some point -
will come to frution, then there's not much left over, what one could wish for in this regard -
(translating higher-level language-instructions into highly optimized Assembly for different arch-backends).

Olaf