Started?

[Aurel]

I was proud of you ...

Such a ordinary lie...

[Peter]

lol, what a funny thread.   

[JRS]

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.

[Charles Pegge]

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

[JRS]

If I understand, the goal is to emit machine readable C code not meant for further interaction by humans.

[JRS]

I was proud of you ...

Such a ordinary lie...

In English, that was a gesture of being sincere.

[JRS]

Where does the O2C emitter stand at this moment? Is a Hello World translation possible?

Code: [Select]

PRINT "Hello World"

Code: [Select]

#include<stdio.h>

main()
{
    printf("Hello World\n");
}


[Charles Pegge]

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

[Charles Pegge]

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

[JRS]

Charles,

Will there be a way to emit inline ASM in the outputted C source? (O2 native pre-assembled code)

John

[Charles Pegge]

Yes, maybe further down the list. The C emitter is primarily for device independence.

[ehitam]

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:

Code: [Select]

#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).

[Charles Pegge]

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

[efgee]

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.

[ehitam]

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
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 so I might be able to help