PureBasic Forums - English

A question: since PureBasic will be based on C, and it used to be based on Assembler, does this mean it won't create a FASM output anymore for compilation, and therefore our apps will run slower?

BarryG wrote:A question: since PureBasic will be based on C, and it used to be based on Assembler, does this mean it won't create a FASM output anymore for compilation, and therefore our apps will run slower?

On the contrary, C compilers tend to produce some of the best/fastest/optimised assembly output, so our apps should run even faster

Sooo we get support for proper unsigned data types?
Still hoping that PB structs also get an upgrade with procedure support (group data+behavior), so instead of just copying plain c structs, improve and ease

Keya wrote:On the contrary, C compilers tend to produce some of the best/fastest/optimised assembly output, so our apps should run even faster

This is if compiling with the -Ofast and -flto flags. If compiling with the -O0 flag and without the -flto flag, then it run be slow.

That whole thing means that PB is going to be PC,
which is a bad thing.

Lord wrote:That whole thing means that PB is going to be PC, which is a bad thing.

How is it a bad thing??? If you mean PC as in desktop computer, that's what PB already is, and changing from fasm to C compiler doesn't change that... in fact it also means it can support other architectures such as ARM/ARM64, as Fred wrote in the blog post.
Or if you meant "PureBasic becomes PureC", no you'll still be writing in Basic code, not C. (You won't need to learn C, just as you haven't had to learn asm to use Purebasic in its current form)

Well, I'm very cautiously optimistic.

It's possible (even if it's not automatically guaranteed) some of the long standing compiler bugs could go away with this.

Also it will be interesting to see what is the C (or C++ ?) compiler used on the various platform.
This could mean better interoperability with C/C++ libraries... possibly.

Another good thing is the code will be generated by a modern C compiler and should be possible to get a higher level of optimizations, and maybe even a larger support of ASM instructions (SSE/SSE2 at least ?)
PB currently generates basically 80386 code.

It remain to be seen the effect of a heavier C compiler instead of a fast assembler on the edit -> compile -> run -> edit cycle.

There's a lot of hope for this news!
But questions about how it will be implemented, will there be a binding to a specific compiler or will we be able to choose in the settings, will the libraries be open, will there be changes in licensing, ..... ?

P.s. Will typed pointers appear?

C PB

https://www.purebasic.com/ wrote:Very fast BASIC compiler ...

Will this be true with a C back-end?

https://www.purebasic.com/ wrote:Using PureBasic is no brainer: you install the program, run the IDE and start developing your application.

Will this be true with a C back-end?

Doubts are quite appropriate.

Lord wrote:

https://www.purebasic.com/ wrote:Very fast BASIC compiler ...

Will this be true with a C back-end?

Yes. The current form of PB is "Basic -> assembly -> executable"
The next form will be "Basic -> C -> assembly -> executable"
Again, don't worry, you won't need to learn C to program in the next version of PB, just as nobody needs to learn assembly to program in its current form. But you will be able to enjoy the benefits of a powerful and mature optimising compiler 'under the hood' creating even more efficient executables for you!

If you're worried about compilation speed, I really don't think that's going to be an issue, especially with gcc (which I'm guessing/assuming will be the C compiler). And if you don't want optimisations that can slow down compilation, you'll be able to set it to -O0 (no optimisation) during development, and only set it to -O1 or -O2 or -O3 etc for your Release build, if you wish. (I say with confidence that these options will be available to us because it's literally just a C compiler parameter flag - trivial for Fred to add support for)
For info about optimisation levels see https://www.linuxtopia.org/online_books ... ro_49.html

I couldn't be more happier or excited

Keya wrote:I say with confidence that these options will be available

I'm not sure about this.
The higher the level of optimization, the more rights the optimizer has to throw out code. If this is not foreseen when translating from basic to C, the code will be inoperative!
Now we do not know anything about the translation from basic to C. I hope Fred comments on this somehow?

User_Russian wrote:I'm not sure about this. The higher the level of optimization, the more rights the optimizer has to throw out code.

Yes, just as they already do with software written in C ... and PB will become C code, so I don't see how it's a problem!? And if the developer experiences problems with say -O3 they can drop back to -O2 or -O1 or -O0 etc
Although, perhaps there might be certain functions used in PB where Fred might want to say "you can't use these (...) particular compiler flags with this particular function" though, for whatever reason, and I'm ok with that
But we're both just speculating here

Unite the community?
https://sourceforge.net/projects/bcx-basic/
https://www.bcxbasiccoders.com/

I have a lot of include and modules in which I use inline ASM code for speed optimization.
Can I still use them for x86 and x86-64 processor architecture or do they become invalid in future PB versions?

Hi folks,

I love reading your speculative thoughts. We should perhaps keep in mind that there is still quite little to be gleaned from the official blog.
I think that too high expectations now are just as premature as concerns or fears.
Let's wait for the first BETA or ALPHA version.

As an optimistic realist, i am looking forward to this new development.