PureBasic Forums - English

RichAlgeni wrote: Mon Oct 04, 2021 5:56 pm

Joubarbe wrote: Mon Oct 04, 2021 4:53 pm Is there any language improvement or new feature planned for PB 6?

Do you understand what moving from x86 Assembler to a ubiquitous C compiler means for PureBasic?

Not really

Joubarbe wrote: Mon Oct 04, 2021 6:39 pm Not really

Interfacing with widely used third party libraries should be a lot easier. No matter if it is parsing webpages, using AI libraries or programming the latest VR toy or robotset. It should also open up the ability to use other existing industry tools. Code verification or teamwork tools, porting to smartphones or even SBC's like raspberry PI could be possible. We will see how interfacing with the resulting translated C-code will work.

Basically - everything that can be programmed, can be programmed using C code on it and gcc is one of the biggest contenders regarding portability and speed. Exciting times.

Joubarbe wrote: Mon Oct 04, 2021 6:39 pm Not really

Basically, anything that the C compiler will compile to, will be able to run PureBasic applications. Up to now, since PureBasic relied so much on x86 assembler, PureBasic could not run on ARM chips. With PureBasic 6, it should be able to do so.

Ok, thanks to both of you.

We do have to back out any ASM code before selecting the C compiler.
Are there any other big syntax changes?

skywalk wrote: Mon Oct 04, 2021 8:32 pm We do have to back out any ASM code before selecting the C compiler.
Are there any other big syntax changes?

I don't see myself writing code for non x86 platforms in the near future, so I will use PB5.7x to compile assembler into DLL's, and use them that way. I am very interested in hearing how others will accomplish this. I imagine that it will be much the same as switching to Unicode based programs: just something we have to get used to.

skywalk wrote: Mon Oct 04, 2021 8:32 pm We do have to back out any ASM code before selecting the C compiler.
Are there any other big syntax changes?

Fred can confirm that but I think ASM code will be available with the C backend but not for version 6.00. Maybe version 6.10 and following one's because to some extent C compilers can deal with ASM code if I recall correctly.

Best regards
StarBootics

Given optimization with gcc and other compilers outperform PB's asm, this is not a high priority for me.
The non-x86 platforms are upon us now. RaspberryPI and many flavored ARM based mini-computers open up a large market and low cost deployment for ioT.

Joubarbe wrote: Mon Oct 04, 2021 4:53 pm Is there any language improvement or new feature planned for PB 6?

Fred has made it very clear that his intention is to avoid all feature changes for this release.

The only real improvement will be compiled code execution speed (but NOT compilation speed), and portability--it opens PB up to different targets, like the raspberry pi or the new ARM based Mac.

Does it mean that there will be some more modern CPU instructions supported in "Executable Format" compiler options?
There are some good perf improvements to be had with some of them.

SSE2 for pentium 4 is over 20 years old now and that's the highest it goes in PB
SSE4.x might be doable with the C compiler.. (I guess?) I notice a new "optimize generated code" option but I'm not sure what it does.

pdwyer wrote: Tue Oct 05, 2021 12:07 pm Does it mean that there will be some more modern CPU instructions supported in "Executable Format" compiler options?

Great question! I would imagine the optimizations brought by the C compiler would be inherent in the new PureBasic executables. But it will be interesting to test them, and see the results.

I am getting a Polink error with the C backend x86 compiler in Alpha 5.
The errors reported are:
POLINK: error. Unresolved external symbol '_PB_Blue@4',
POLINK: error. Unresolved external symbol '_PB_Green@4',
POLINK: error. Unresolved external symbol '_PB_Red@4',
POLINK: error. Unresolved external symbol '_PB_RGB@12',

The errors do not occur with the x86 asm compiler or with either the C backend or asm compilers in x64.

Why didn't you post in the 'Bugs - C Backend' forum and where's the code that generated the errors?

I was not aware there is such a forum. The code is buried somewhere in tens of thousands of lines but I will try to narrow it down. I thought the error messages might be enough to give a clue.

Found it. The error comes from either RGB( ) or Red(x), Green(x) or Blue(x) functions. I have posted a report in a C-backend 32-bit error forum I found. Hope it is the right place. A simple Debug RGB(164,0,0) will generate the error.