Oxygen Basic
Information => Development => C Emitter => Topic started by: efgee on August 16, 2012, 12:28:38 PM
-
Charles,
did you already start on this?
-
Yes, I have made a tentative start, I can produce a naive version quite easily, but some Oxygen constructs have no counterparts in C.
Charles
-
There is a point were cool loses to portability. I'm confident your will find the answer.
-
Understood.
If the problem is on the oop side of things:
Here is a nice pdf file explaining how to oop in c: www.cs.rit.edu/~ats/books/ooc.pdf (http://www.cs.rit.edu/~ats/books/ooc.pdf)
Then there are some libraries that help with it:
http://sourceforge.net/projects/cos (http://sourceforge.net/projects/cos)
http://sourceforge.net/projects/ooc-coding (http://sourceforge.net/projects/ooc-coding)
http://sourceforge.net/projects/sooc/ (http://sourceforge.net/projects/sooc/)
http://sourceforge.net/projects/oooac (http://sourceforge.net/projects/oooac)
http://sourceforge.net/projects/lwoopc/ (http://sourceforge.net/projects/lwoopc/)
https://code.google.com/p/ooc-gcc/ (https://code.google.com/p/ooc-gcc/)
Don't know if they are any good as I've only worked with one of them in the past (an older version of cos).
EDIT:
found another one:
http://code.google.com/p/cluscore/ (http://code.google.com/p/cluscore/)
-
There is a point were cool loses to portability. I'm confident your will find the answer.
;D
.
-
OOP isn't a problem, it is local macros, nested functions and run-time compiling.
-
Didn't you get the memo?
Macros are evil :P
-
Nested functions could be created with a goto inside the function could they not?
(at the end of the parent function after a function return)
The name of a label should be created with both function names -> parent and nested functions.
It sounds too easy, I'm surely missing something...
-
Didn't you get the memo?
Macros are evil :P
If that is the case, ScriptBasic is the Devil in the flesh.
The SB extension module interface is almost exclusively macros. I never considered macros a porting issue since SB pretty much runs on everything.
I know this might sound crazy but isn't the goal here to create a text file that C will compile? With enough C code, anything can be emulated. Don't forget about all the existing libraries that are there to make your life simple. Charles, I don't think anyone is asking you to compromise the O2 code for an emulation that runs outside the box.
-
Yes you can do almost anything with C, and most of Oxygen's special features can be emulated by using extended labels and symbols in the global namespace. It just requires extra work.
-
I want to make sure we are all on the same page with this effort. The C emitter is a convenience feature of O2 while you continue to develop and port your JIT compiler. Anything more is going in the wrong direction. IMHO
Just to keep the separation of state intact, we should write the O2 Basic to C converter in SB so more folks can contribute. I have already started thinking about the fun I'm going to have writing a SB extension module to cover the areas best done as a C wrapper.
-
we should write the O2 Basic to C converter in SB so more folks can contribute.
This is the dumbest thing I've ever heard.
And where are those folks...?
Who will write this ...you John.
Oxygen syntax is far better then this that's for sure.
But because i am not interested i will shut up... :-X
-
Aurel,
Go take your meds and chill out. You are acting like a spoiled brat again.
-
Why insult ;D
I just say what i think of your idea where everything started with SB.
James have more expirence then anyone in translators(BCX),right...
Beep ...i use my pill... ;D
-
Okay, I'll ignore for now you calling me stupid and then ranting about things you know nothing about.
Why I suggested ScriptBasic.
- Charles is intimate with the internals
- It runs on all popular platforms including Android.
- ALL scripts and extension modules play the same tune.
- It would make a good tutorial on compiler design at a level us mortals understand.
I was proud of you turning your act around and finding meaning with your work. Please allow others to enjoy their efforts and contributions.
-
I was proud of you ...
Such a ordinary lie...
-
lol, what a funny thread. :D
-
What the O2 translator is written in at this point is meaningless. What we need is C code emulating O2 functionality or an outline of the project. What automates that process and the platforms it supports is still on the table as I see it.
-
There's about 48000 lines of code to consider. And it has to be frozen while porting, since multiple versions would be unmanageable.
Getting the C-emitter working is a much nearer goal. In terms of development time, it would be similar to implementing 64 bit code.
Charles
-
If I understand, the goal is to emit machine readable C code not meant for further interaction by humans.
-
I was proud of you ...
Such a ordinary lie...
In English, that was a gesture of being sincere.
-
Where does the O2C emitter stand at this moment? Is a Hello World translation possible?
PRINT "Hello World"
#include<stdio.h>
main()
{
printf("Hello World\n");
}
-
Not yet John. I'm still rearranging code and studying some of the hard stuff.
2 key commands proposed:
#file "Myprog.c" 'Activates C emitter (this directive is already used for exe and dll)
#emit { .. } 'To emit code (native headers etc) directly without translation.
Charles
-
Further extension the the #emit directive:
#emit enable
#emit disable
This allows local declarations to be made, but not passed on to the host compiler.
Charles
-
Charles,
Will there be a way to emit inline ASM in the outputted C source? (O2 native pre-assembled code)
John
-
Yes, maybe further down the list. The C emitter is primarily for device independence.
-
Yes, maybe further down the list. The C emitter is primarily for device independence.
With C emitter you can include a compiler too. I have checked tiny C compiler(tcc). Its code is almost over 10 times smaller than GCC(I haven't tested speed...).
I compiled following program in both GCC and TCC:
#include <stdio.h>
int main(){
//Variable declarations:
int age;
char name[20];
printf("Enter your name: ");
gets(name);
printf("\nHello %s! How are you?", name);
printf("\nPlease Enter your age: ");
scanf("%d", &age);
if (age>= 18){
printf("\nWelsome to voting booth Mr.%s. You may vote!", name);
}
else{
printf("\nGet your dirty hands away from voting!!! stupid n00bish kiddu!");
}
return 0;
}
GCC output: 48.8 KB
TCC output: 1.5 KB
And TCC is less than a MB(934 KB).
-
Hi Ehitam, and welcome to the forum!
Yes, the main idea is to be able to generate source code for the native compiler supplied on any platform, which usually turns out to be GCC.
The main problem I am trying to resolve is how to handle constructs which are not directly supported by C. One possibility is dropping down to the lower level: LLVM. But this is a strange beast. Unlike Java byte code and Ms Common Intermediate language, it does not offer a stack.
Charles
-
Years ago I used tcc and Agner Fog's objconv to create different obj file formats because tcc only creates ELF obj files and objconv can convert any obj file format to any obj file format (x86-64 platforms: PE, COFF, ELF, OMF, MACHO).
With this I was able to test the 32bit/64bit obj file integrity from the obj files created by tcc.
The 64 bit obj file tcc created was NOT OK.
That's where I stopped using tcc.
The footprint and speed of tcc is awesome, but the tcc code-base is a mess.
And the folks at the tcc mailing list had no interest in fixing this problem.
-
Hi Ehitam, and welcome to the forum!
Yes, the main idea is to be able to generate source code for the native compiler supplied on any platform, which usually turns out to be GCC.
The main problem I am trying to resolve is how to handle constructs which are not directly supported by C. One possibility is dropping down to the lower level: LLVM. But this is a strange beast. Unlike Java byte code and Ms Common Intermediate language, it does not offer a stack.
Charles
BASIC don't have single good compiled implementation. FreeBASIC was going pretty well but most of the development seems to be done on first 5 months :P
Well it lacks 64 bit support which is biggest problem. While I generally support C solution but it should not because main way your language is implementation. This should be used to make language powerful for a while eternal crusade to win Assembler war should be continued. If academia and professionals see that we have no plan to make assembler our primary back end they wouldn't take it much seriously and here goes lot of free publicity and availability of huge 3rd party resources.
Which constructs you need help with? I'm C-Fanatic :P so I might be able to help :)
-
Most of the complexity, converting to C, is around strings and automatic number/string conversions within an expression.
Oxygen currently translates basic expressions to assembly code in two passes. At least one further intermediate pass is required to turn implicit code into explicit c-friendly code before generating assembler.
Typical Basic string expression, requiring break-down for C.
string a,b,c,d
int n
...
a=ltrim(mid(b+c+d,n))
Charles
-
It seems that your problems never end, and your time runs away.
-
Some problems are interesting, others only cause headaches.
This one, I hope, belongs to the first category, but time is a limitation I agree.
Charles
-
Charles,
I would hate to see the OxygenBasic project (Basic JIT/embeddable compiler for Windows 32/64) be derailed due to the perceived need for a C emitter.
As I understood the last time I checked the OxygenBasic project status was that you were working on self compiling and 64 bit. You were also allowing C header (.h) file use in O2.
The C thing came up and everything seemed to stop. (just an observation)
John
-
Maybe i'm in wrong , but I think that work on C emiter is just a waste of time.
Important (to me) will be remove as possible more bugs or errors and create
really stable product which be capable do things like any other very well basic-like compiler
around.
There is a time for C emiter... ;)
-
I've been quietly restructuring Oxygen,to make the back-end more flexible - not just for the C-emitter. It will take me a few more months, but we will end up with an improved compiler. This process is similar in some respects, to developing 64 bit compilability last year.
Thanks to all your code examples and challenges, testing is much more rigorous on this development cycle.
Charles
-
Thanks to all your code examples and challenges.
How many month will it need? I mean, when I have questions, where find I an answer?
-
I anticipate late December, Peter. No problem answering well framed questions, but I would prefer to avoid library stuff, or anything which might entail lengthy research. :)
This is a simplified scheme. The new parts being developed are colored Navy Blue:
/-->32/64 encoder-->assembler-->linker-->x86 code
Translation-->construct-->expression-->instruction
\-->C encoder-->c source code
Charles
-
Is no long time! Seems not too difficult.
I hold my questions, when I have any, very easy. Only Aurel makes worries me. :D
I have new Dll stuff, that must be tested under WindowsXp and Vista.
Under Windows7 is anything okay. It only needs still a help tutorial.
-
Only Aurel makes worries me.
Why?.. ;D
Do you can explain?
-
Is no long time! Seems not too difficult.
I hold my questions, when I have any, very easy. Only Aurel makes worries me. :D
I have new Dll stuff, that must be tested under WindowsXp and Vista.
Under Windows7 is anything okay. It only needs still a help tutorial.
Peter,
I have learned that if you want anything to get done, (right) you have to do it yourself. I'm trying to generate some interest with the ScriptBasic 2.2 (http://forum.basicprogramming.org/index.php/topic,2726.0.html) cross platform release and there doesn't seem to be much interest. I think James is seeing the same kind of response with his BCX release. I should be spending my time on the Android side were a hobby project can easily become profitable with little effort. You are a talented guy and should take look at Basic4Android as your next platform to conquer.
John
-
Hi John,
I learned the same.
Your idea isn't bad, but unfortunately, there is no Android here with me.
What is the challenge? I master this Basic, and when an Android comes, I'm prepared.
-
Your idea isn't bad, but unfortunately, there is no Android here with me.
Sure there is. Windows supports running Android in a VirtualBox (emulator) and Basic4Android is a 32 bit Windows Application. You could do everything on your Windows PC. When you feel that your ready to start developing for Google Play, you should get yourself an Android based tablet to work with.