CodeRefractor has some clean advantages over other static compilers that target LLVM by targetting C++ but also some disadvantages.
One great advantage is that it is written in .Net and it bootstraps everything needed for output, and the output is somewhat human readable result. This also allows simple optimizations to be done as CR rewrites everything into an intermediate representation (IR) and this representation is simplified with many high level optimization steps.
So this instruction was in the past setup as a list of pairs of values: instruction kind and the instruction data and many casts were made based on this instruction. This is good design, but right now the code is represented as a specific instruction class. So if in the past for storing a label, you would have something like: pair of (Label, 23) where 23 was the label's name, right now is a class Label where it stores: JumpTo property which is set to value 23.
Similarly, more changes are to debug methods, in the past there was a similar pair of the method kind and a MethodInterpreter, and sadly the MethodInterpreter type will store based on the kind of method various fields which some of them were redundant, some of them unused, and changes of this kind. As the code right now is split, the experience in debugging CR is better also.
At last, but not at least, even is not yet fully implemented, it is important to say that the types right now are resolved using a construction named ClosureEntities, and there are steps (similar with optimization steps) that they find the unused types. This also will likely improve in future the definition of types and make possible to define easier the runtime methods. This new algorithm has one problem as for now: it doesn't solve the abstract/virtual methods and the fixing of them will be necessary in future.
Hi, Ciprian.
ReplyDeleteI found this project very interesting, unfortunatelly I could not make it to run.
As I'm not a C# guy (nor a C++ one for what it matters...) I am not going to submit any fixes, however, is there any way I can inform you about my issues?
Best regards,
Oracy.
A fix for #4 was added, but the remaining issues are mostly easy to fix but takes a lot of debugging:
Delete- we sort types and your code hangs it
- we register by mistake the type String& when we should register just String (in fact CrString, our mapped type for String)
- there is no marshaling logic for now, so for example when you call using strings, in fact there have to be a mapping to the internal char array that the string holds.
CR generates something like:
return dll_method_1(hWnd, lpText, lpCaption, uType);
But it should be:
return dll_method_1(hWnd, (*lpText)->Text->Items, (*lpCaption)->Text->Items, uType);
At last, probably on VB or on the environment you're using the default calling convention is StdCall, so maybe CR should use StdCall by default on 32 bit machines at least.
You call MessageBoxA and I think it should be MessageBoxW.
My point is that all these fixes they are compiler related but we cannot fix them right away as they are not overly difficult, but take time to fix and take the proper decision.
So if you have courage, look just into PlatformInvoke code (are not so many points) and you can try to add fixes related with this (any small fix you can) and we will be glad to support you.
You can use GitHub's Issues page:
ReplyDeletehttps://github.com/ciplogic/CodeRefractor/issues
If you don't have an account try make a video recording and see where you are blocked:
http://www.screencast-o-matic.com/
and post the link here.
Me or Roland as we see where you are blocked, we can add as a comment how to address the issue.
In short:
1. download Visual Studio Express/SharpDevelop.
2. Get Git sources
3. Start either: VisualConsole or CodeRefractor.Compiler project in solution CodeRefractor.sln