PureBasic Forums - English

Posted: **Tue Jan 12, 2010 11:07 am**

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

Posted: **Tue Jan 12, 2010 11:36 am**

Foz wrote:...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

Posted: **Tue Jan 12, 2010 3:36 pm**

milan1612 wrote:
Fred wrote: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).

Posted: **Tue Jan 12, 2010 4:14 pm**

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

Posted: **Tue Jan 12, 2010 6:23 pm**

milan1612 wrote: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]

Posted: **Tue Jan 12, 2010 6:47 pm**

Thorium wrote: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

Posted: **Tue Jan 12, 2010 7:27 pm**

Fred wrote:
milan1612 wrote:
Fred wrote: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...

Posted: **Tue Jan 12, 2010 7:28 pm**

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.

Posted: **Tue Jan 12, 2010 7:57 pm**

milan1612 wrote: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?).

Posted: **Tue Jan 12, 2010 8:37 pm**

Trond wrote: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...

Posted: **Tue Jan 12, 2010 8:59 pm**

Foz wrote: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.

Foz wrote: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.

Trond wrote:(why else would we use PB?).

Mmm, it's like comparing this with this

Posted: **Tue Jan 12, 2010 9:04 pm**

Foz wrote: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

Posted: **Tue Jan 12, 2010 9:15 pm**

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

Posted: **Tue Jan 12, 2010 9:26 pm**

milan1612 wrote: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

milan1612 wrote: 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.

Posted: **Tue Jan 12, 2010 9:32 pm**

fsw wrote: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.

PureBasic Forums - English

PB written by which language?

Re: PB written by which language?

Re: PB written by which language?

Re: PB written by which language?

Re: PB written by which language?

Re: PB written by which language?

Re: PB written by which language?

Re: PB written by which language?

Re: PB written by which language?

Re: PB written by which language?

Re: PB written by which language?

Re: PB written by which language?

Re: PB written by which language?

Re: PB written by which language?

Re: PB written by which language?

Re: PB written by which language?