Very experimental support for LLVM in DWScript is now in the googlecode repository, thanks to the efforts of Christian-W Budde.
This is the beginning of the opening of new realms of possibilities for DWS!
LLVM support is currently centered around jit compilation, and at the moment doesn’t extend much beyond the needs of the Mandelbrot demo (see below for what is supported right now).
LLVM CodeGen vs dwsJIT
Note that it is a different effort from the recently announced JITter for DWS, the TdwsJIT is a simple greedy just in time compiler, which works on the same structures as the interpreter, and where a goal is that jitting should be lightweight and fast enough to be applied all the time. It’s a “cheap” boost to script execution, and a hybrid architecture (cf. future article).
The LLVM codegen on the other hand involves a bit more overhead, in terms of a large DLL and longer compilation/JITting times, but has a wealth of other benefits.
The LLVM codegen isn’t tied to the interpreted structures, so it means more work down the road to get everything working, but there is much greater optimization potential, and the natively compiled code can be cached or persisted (thus mitigating or negating the compilation overhead).
Finally LLVM is of course cross-platform, and there is the potential for compiling standalone binaries as well…
Performance
No exact performance figures just yet, it’s too early and they change too often!
From initial tests, LLVM with optimization level zero (no optimization) is in the same ballpark as the dwsJIT, though with a slight JIT overhead (dwsJIT has none).
When increasing the optimization level, LLVM takes a measurable amount of time, but produces the best compiled binary on the benchmark so far! It’s only behind the hand-optimized version, and not all optimizations in LLVM are active just yet…
What’s working
Note that this is a very temporary list, as things change rapidly, so use it more as “cheat list” for what you can test right now.
What is working so far:
- Primitive expressions
- Integer
- Arithmetrical (Add, Sub, Mul, Div, Mod, Neg, Sqr & Abs)
- Arithmetrical assigns (+=, *=, -=, …, see above)
- Bit Manipulations (Sar, Shr, Shl, And, Or, Xor, Not)
- Comparisons (Less, LessEqual, Equal, GreaterEqual, Greater)
- Shortcuts such as Inc & Dec
- Min & Max (inlined)
- Float
- Arithmetrical (Add, Sub, Mul, Div, Neg, Sqr, Abs, Sqrt, Sin, Cos, Power, Exp, Ln, Log10, Log2)
- Arithmetrical assigns (+=, *=, -=, …, see above)
- Conversions (Floor, Ceil, Trunc, Round)
- Comparisons (Less, LessEqual, Equal, GreaterEqual, Greater)
- Min & Max (inlined)
- Boolean
- Logical (And, Or, Xor, Not)
- Integer
- Aggregate Types
- Arrays
- simple array types (read only!)
- only primitive types
- Records
- simple record types
- nesting is not thoroughly tested yet
- may not contain arrays
- Strings
- only constant strings
- Arrays
- Control Flow Expressions
- Branches
- If / Then
- If / Then / Else
- If / Then / Else -> Value
- Loops
- while
- repeat
- for (upward / downward, fixed / variable steps)
- Functions
- using simple variables (no var or const yet)
- main function (typically without declaration in DWS)
- may be called from other functions
- PrintLn (to print constant strings, rely on external definition)
- Branches
And here’s the list of things that are not working:
- Strings and string management (except for string constants)
- obviously no helpers as well
- Resource strings
- Dynamic arrays
- Variants
- complex array types (containing non-primitive values)
- complex record types (containing non-primitive values)
- Classes
- Fields
- Methods
- Constructors
- Self
- Visibility
- Interfaces
- Objects
- Case
- Special loop aware
- ForCharIn / ForCharCodeIn
- Continue / Break / Exit / Exit(Value)
- Exceptions (try, finally, except, raise, assert)
- Helpers
- Connectors
- Special math functions like Tan, Arc*, etc.
Eric, tell you straight if you would bring to life the theme with llmv, you OPEN a new page in the history of pascal. You know perfectly well that the emb will soon finally bury the delphi, and Lazarus just do not meet modern requirements! You are the only chance to prolong the life of our beloved language.
Also just don’t say that remobjects done in nougat – they just chose the wrong path, adapting language to the system, it is a road to nowhere – there is no point in writing to anyone oxigene, if just as well you can do it on native object-c.
Also in my opinion it was a mistake by giving your js-compiler in proprietary use of smartmobilestudio – the system got confused and not entirely successful, I think you already know, after almost 2 years – it did not go.
And if you will add support of asm.js which will be supported by google in v8 and chrome – it will be the very sucsessfull tandem.
Please give pascal a chance to survive!
This is getting hot!
@Sergionn
What do you mean by “the system got confused”?
Smart has been in the market for 1 year (not 2) and it’s growing.
The fact that DWS receives steady income from each Smart-sale makes it possible for Eric to dedicate time to the general development of DWS.
@Sergionn there is a world of difference between a compiler and an environment, as it means RTL, IDE support, giving access to external libraries, etc. this is why SlartMobileStudio, Delphi, Visual Studio, etc. are so much larger than their compilers. So there is an awful lot of work before it could start to begin being an alternative to Lazarus f.i., years, decades.
As for SmartMobileStudio, it’s much ahead in the curve, it’s possible to release web apps with it, and a key, highly complex piece of our app (at work) will be using it, which AFAIK no other tool could have allowed from a single-source base with a comparable platform coverage and performance level (thanks ubuquitous hardware accelerated Canvas!!)
@Jørn E. Angeltveit
I could be wrong, but comparing the two factors seemed to me that your project does not go:
No much activity on the forum, social networks, and at the same time for at least 4 of my requests as a potential long-term user of smart you have not reacted:
1) Add a structure “set of” – I think that is easy
2) Add generics – very important
3) Inline functions
4) Add a library project template – not only me asked
If you whant old delphi users start develop on smart first 3 item just must to support in smart, if you don’t – when why new developers have to use smart and not typescript or something else. As a result, i started to port code to typescript.
Maybe all of this offers don’t fit into your development strategy and maybe somewhere else exists fast growing community of which i don’t heard and you got so much responses and so much money – so you just don’t need to listen for me.
Did not mean to hurt or offend to you, good luck to your project!
@Sergionn
1) The problems around this one relates to how it “squats” the most logical operators for array operations and inline declaration… ie is [a, b, c] better understood as an array of a set? and is [a]+[a, b] better understood as an array concatenation (resulting in [a, a, b]) or as a set union (resulting in [a, b]). While sets have their uses, array comprehension is very useful as well…
2) They’re under consideration, but the extended array support, type inference and lambdas have drastically reduced their usefulness compared to classic Delphi. So while they’re coming, they’ve been displaced somewhat in the priority list.
3) Support for the syntax hint will be added for compatibility, but JavaScript engine can already do inlining without hinting.
4) Many things underway and coming on that front 🙂
Eric, thanks for responce, but just try to understand one simple thing – me, and not only me, whant to SHARE the same code on smart and delphi – this is have to be the big idea of your project.
If we can’t do that, reason to pay almost 400$, study pascal-language, (which almoust out of trend) or continue use it, and rely on possibility of long and success life of smart i don’t see, nobody see. If i don’t need compability with delphi – i will go to 100 differents platforms, but i need it – and i need compability with delphi. Just think about it.
And thanks for some reaction on my post…..
@Sergionn Compatibility is increasing step by step.
@Sergionn Delphi compatibility would be awesome but everything takes time. It’s awesome to see people working on pascal related tools.