PB written by which language?

[Foz]

The problem isn't the language conversion, the problem is the PB library framework that C doesn't have access to.

[milan1612]

...the problem is the PB library framework that C doesn't have access to.

Actually it does, the PB libraries are just packed static libraries as far as I know.
No problem linking against that

[Fred]

Nop.

It would be possible though? What amount of work would you reckon it'd be for you?

Sure, eveything is possible. But it will not fit right with the current expression parser, so the generated code will be really unoptimized (but working i guess).

[milan1612]

How do you parse the expressions? I guess it's best to parse them into a recursive
tree structure. For a C output, you would just have to serialize the tree back to C
syntax expressions, let the C compiler do the optimiziations.

I'm yet to find a PB syntax feature that can't be represented directly in C syntax

EDIT: I've played with the thought of writing a PB to C converter before, but
didn't do it 'cause there's no official specification describing the syntax.

Also, boolean expression behaviour is somehow undefined, at least it seems so to me...

[Thorium]

let the C compiler do the optimiziations.

Not a very good idea. Don't just trust the compiler to optimize every bad code.
C/C++ compilers are very good on optimization but they don't beat hand optimized code. Many people say that C/C++ compilers compiling allways the best optimized code and that it even makes no sense to use inline assembler. But thats just very wrong.

To just show you a example of failed compiler optimization. The following code was generated by VC++ 7:

Code: Select all

MOV EBP,ESP
PUSH ECX
MOV DWORD PTR SS:[EBP-4],ECX
MOV ECX,DWORD PTR SS:[EBP-4]

[fsw]

To just show you a example of failed compiler optimization. The following code was generated by VC++ 7:

Code: Select all

MOV EBP,ESP
PUSH ECX
MOV DWORD PTR SS:[EBP-4],ECX
MOV ECX,DWORD PTR SS:[EBP-4]

How many people are working on the Visual Studio compiler 10? 20? 40? 80?

Good job guys

[fsw]

Nop.

It would be possible though? What amount of work would you reckon it'd be for you?

Sure, eveything is possible. But it will not fit right with the current expression parser, so the generated code will be really unoptimized (but working i guess).

Suppose emitting C code would only make sense if PureBasic would have a target processor different from X86 or X86-64.
Nowadays the only feasible target would be ARM, but Intel is moving into the same low power arena, so burning man hours implementing an ARM emitter into PureBasic would just be a learning exercise.

And with only 2 programmers taking care of bussiness (Fred & Freak) it doesn't make sense ( IMHO ).

Too much to do, so little time...

[milan1612]

Well Thorium, I don't know assembler, I can't even read it mostly, but if I learned anything
in the past years, then it's the fact that you don't need hand-written assembler in almost
all cases. Imho, that's just premature optimization. But still, you have a point there

Having the PB compiler output C, would be great. Having the PB compiler output slow, but
valid code C code for expressions wouldn't be too bad. You could still tune the code after
the conversion by hand - like you can with the assembler output of the PB compiler.

[Trond]

How do you parse the expressions? I guess it's best to parse them into a recursive
tree structure. For a C output, you would just have to serialize the tree back to C
syntax expressions, let the C compiler do the optimiziations.

It isn't that easy because PB's rules of expression evaluation are different from C.

Code: Select all

Double.d
Int1.i = 3
Int2.i = 2
Int3.i

Double = Int1/Int2
Int3 =   Int1/Int2

Debug Double ; This would be 1.0 in C.
Debug Int3

Also, what would the point be? C compilers are ten times slower than the PB compiler and there always seems to be an endless list of shouldn't-really-be-a-problem problems with C (why else would we use PB?).

[Foz]

Also, what would the point be? C compilers are ten times slower than the PB compiler and there always seems to be an endless list of shouldn't-really-be-a-problem problems with C (why else would we use PB?).

The only reason i would have is when I get a Linux ARM computer (here's to saving up for the Nokia N900), being able to code in PB rather than C would definitely be a great help

Switching between C and PB is a pain - I'd rather use one language, otherwise you start to blend languages, i.e. putting a semi colon at the end of the PB line and missing them in the C lines...

[the.weavster]

The only reason i would have is when I get a Linux ARM computer (here's to saving up for the Nokia N900), being able to code in PB rather than C would definitely be a great help

I think that's a pretty good reason and it's really why I asked the question.

Switching between C and PB is a pain - I'd rather use one language, otherwise you start to blend languages, i.e. putting a semi colon at the end of the PB line and missing them in the C lines...

All those curly brackets and semi-colons - whoever invented C must have had a punctuation fetish.

(why else would we use PB?).

Mmm, it's like comparing this with this

[fsw]

The only reason i would have is when I get a Linux ARM computer (here's to saving up for the Nokia N900), being able to code in PB rather than C would definitely be a great help

I'm with you on this one, if only the N900 would have a real compass...
Could live coding in C or something different (as long it's not Python )

BTW: while talking about it: does anybody know a easy to read (and understand) ELF executable file format document?
Need to know (and understand) the structure differences between PE and ELF executables. Thanks

[Trond]

Making the pbcompiler output C code wouldn't let you develop for arm because the libraries are platform specific.

[Thorium]

Well Thorium, I don't know assembler, I can't even read it mostly,

What the code does it reads a value and writes it back.
In PureBasic it would be:

Code: Select all

a.i = b.i
b.i = a.i

but if I learned anything
in the past years, then it's the fact that you don't need hand-written assembler in almost
all cases. Imho, that's just premature optimization. But still, you have a point there

It isnt premature optimization if you get 1000% speed up. Which isn't unrealistic. If you process large data blocks writing the routine in assembler can give you a huge speed up and using extensions like SSE can boost the performance of your assembler code by like 10 times. Depants strongly on your algo, but thats not premature optimization at all.

[the.weavster]

Could live coding in C or something different (as long it's not Python )

I really love Python, but I'm not sure the current generation of mobiles are powerful enough to do it justice.