Here is a summary of recent changes for DWScript in the SVN:
- support for compile-time evaluation of constant records and static arrays.
- support for the ‘&’ escape prefix to allow using reserved words as identifiers.
- fledgling math extensions (TComplex, TVector & TMatrix), currently they are still incomplete, slow and experimental.
- added fledgling language doc in the wiki, redactors and help welcome!
- several units were split: dwsSymbols to dwsUnitSymbols, dwsExprs to dwsInfo, and dwsFunctions to dwsMagicExprs. Advanced script users may have to update some of their “uses” clauses.
- system & internal units are now “static” by default, this is mostly relevant if you were compiling lots of simple scripts, as it saves about 40 kB per script and reduces compile times for short scripts to a matter of nanoseconds.
As a consequence of the above, the unit tests suite now runs quite a bit faster… actually DUnit’s TreeView updates are now the bottleneck, despites hundredths of scripts getting compiled and executed at each step. Time to add more unit tests I guess 😉
Vector and Matrix support have actually been a “fuzzy” goal for DWS, since a long time ago, which is only now getting implemented. The plan is to eventually have them use SIMD, and possibly be part of a future OpenCL CodeGen target.
After seeing what you did on JavaScript code generation. OpenCL & SIMD would be just plain amazing.
You rock!
Hi Eric,
Just awesome, really. I work a lot with PaxCompiler, but I ask myself to drop all and work with DWS when I see JS emiter perf. 🙂
Just some questions :
– What is the link with OP4JS ? What OP4JS give us compare to DWS last SVN trunk ? I see OP4JS will be a commercial project or I’m wrong ?
– I work with OpenCL for Delphi too (http://www.objectupstudio.com/CaptureOpenCL.png), When you said
“OpenCL Code Gen” what will be exacly done ? I mean, what will be emit ?
–> OpenCL “c” code (before vendor compiler pipeline)
–> Another level code (in this case I do not understand, it will be a little bit magic :))
Above all, it look like a rock promising stuff.
Congrat !
Vincent
@Vincent
OP4JS is using DWS, but worked on by Jon Lennart & his company. Ts relatinship with DWS is a bit like what Delphi IDE + VCL brings to DCC32 + RTL, ie. an IDE, visual & non-visual libraries etc.
For the OpenCL the idea would be to compile whole (or more likely, portions) of a script to “OpenCL C”, in a “transparent” fashion (just like the JS codegen, you would be able to use it as a black box or as an intermediate tool).
hi Eric,
Thanks for dws vs op4js info : very clear !!
I undestand now how the js gen from Dws work basically, a kind of source converter in a way.
I will look this deeper, the js generator work certainly starting from the dws vm byte code ? I’m curious to dig in !
Bon courage pour la suite de ce projet, Eric ! 😉
A+
Yes, though DWS doesn’t use a bytecode but an expression tree, which means it can generate code from a higher level representation, almost a like a code DOM in some cases (and I’ve vague plans to fill in the gaps, so it can be used for more refactoring than currently possible).
Ok, Expression tree -> That explain the “clarity” of the resulting code.
Is examine shortly the js generation code, beyond the well written style, there are a lot of work. As you done on glscene, I’m impressed.
I will conduct some benchmark for the js side, (delphi, PaxCompiler, DWS2JS) I believe, If you are interested, send me a mail, I’ll keep you in touch by mp, or simply by this blog way.
bye,
@Vincent
Message or blog is okay, though blog comments on a post are locked after some time to minimize spam.
On the JS performance side, the codegen doesn’t make use of JS typed arrays yet, theoretically that could bring huge speedups, but in practice, it seems not all JS engines make proper use of them just yet, so results are mixed. The situation could be evolving rapidly though, so benchmarks of today will likely give different results than those of yesterday and tomorrow 😉