PureBasic Forums - English

Posted: **Mon Mar 15, 2021 10:16 am**

That's a lot of comments about the new back-end

! Let's clarify some points:

- The x86-x64 asm compilers will still be supported, we don't have a plan to drop them at this point
- The C backend will take time to mature, but will be available for all platform to make it better. It will be based on gcc, and shipped in the PB installer for Windows (nothing to install, plug and play). You could choose your compiler like you do when installing several version of PB)
- Inline C will be supported
- Inline ASM won't be supported directly at start. We plan to add naked ProcedureASM : EndProdecure which will create an assembly file, use fasm and link it to the final exe without needed to do anything
- Compilation in dev mode should be fast as we disable all optimisation in the C compiler and we don't have any include file (flat .c file)
- Compilation in release mode will be much longer, but will produce much faster code especially on processing code (heavy memory data manipulation). If you don't have a lot of processing in your app, and using mostly PB commands, it shouldn't have a big difference.
- From an user point of view, you shouldn't notice anything unless you deal with inline ASM
- It could be some limitation in the C back-end (we have trouble to implement GOSUB properly for example), but it should be very specific and not core functions.

I will do a series of post on the blog regarding the progress and going deeper about this choice, with PRO and CONS about this.

Also don't get too excited, it's not ready for release, even alpha. For example the debugger is not supported yet

Posted: **Mon Mar 15, 2021 10:39 am**

the.weavster wrote:
Danilo wrote:Beside BCX there is also Wonkey (github.com/wonkey-coders/wonkey) which translates to C++ and can import C and C++ libraries.
Looks cool but I couldn't find a Get Started tutorial

You may want to join the Discord Chat to ask questions.

the.weavster wrote:And an example of importing C (preferably webview) would be very interesting

You need to write a module like the included modules (SDL2, GLFW, Sokol, pigpio, etc.)

Examples:
- /modules/raspberry/pigpio/pigpio.wx
- /modules/stb-image/stb-image.wx
- /modules/sqlite/sqlite_extern.wx

You basically just import .h/.hpp/.c/.m/.mm/.cpp/.a/.o/.lib/.framework/.dylib files and write struct/function declarations.

Posted: **Mon Mar 15, 2021 10:41 am**

Regarding that we can choose which compiler to use: Does this mean the compiler we use at the moment will still be in development?

Also, and please remember I'm still new to PureBasic, I never used gosub and from what I heard about other languages it's obsolete (e.g. XProfan dropped a while ago). Is this really needed in the future?

Posted: **Mon Mar 15, 2021 11:45 am**

Fred wrote:we have trouble to implement GOSUB properly for example

I think that gosub can be abandoned.

Fred wrote:don't have any include file (flat .c file)

C supports separate compilation (each c file is compiled separately). This allows you to run how many instances of the compiler, how many cores there are in the processor. This will speed up compilation.

Posted: **Mon Mar 15, 2021 11:49 am**

Is compilation speed really so important? I only have small projects which never take then more than 3 seconds or something, usually less.

Posted: **Mon Mar 15, 2021 12:09 pm**

Fred wrote:- The C backend will take time to mature, but will be available for all platform to make it better. It will be based on gcc, and shipped in the PB installer for Windows (nothing to install, plug and play).

With gcc compilers for other platforms too so we can cross-compile?

Posted: **Mon Mar 15, 2021 12:25 pm**

Fred wrote:That's a lot of comments about the new back-end ! Let's clarify some points:

Thanks for the additional info.

- The x86-x64 asm compilers will still be supported, we don't have a plan to drop them at this point

That's very nice to hear, especially for people who is currently investing in building something big enough with PB.
Would be awesome to have both until the C backend has proven itself and there are no missing features or capabilities.

You could choose your compiler like you do when installing several version of PB)

That's a nice feature.

- Inline C will be supported

Awesome

- Inline ASM won't be supported directly at start. We plan to add naked ProcedureASM : EndProdecure which will create an assembly file, use fasm and link it to the final exe without needed to do anything

It's still a nice way to do it considering the changes.

- Compilation in dev mode should be fast as we disable all optimisation in the C compiler and we don't have any include file (flat .c file)
- Compilation in release mode will be much longer, but will produce much faster code

This is a little step back to me because now when the debugger is disabled and I do a quick F5 compile in the IDE the resulting program performs like the final program will do.
In the future the code will not be the same, and I'll have to compile in release mode to actually test the performance (and correctness) of the program.
It was a very nice advantage of the PB dev environment.
F5 with optimizations disabled will be enough most of the times but not always...but I was expecting this and there is not much you can do.
Maybe we could have an option to trigger the full slower compilation mode in develop mode too (when the debugger is disabled obviously) to test the actual code without the need of the steps of selecting the output filename, run the program externally, etc.

I will do a series of post on the blog regarding the progress and going deeper about this choice, with PRO and CONS about this.

I look forward to those.

Posted: **Mon Mar 15, 2021 12:34 pm**

Fred wrote:- Compilation in release mode will be much longer

If time is going to increase, you may as well make it a two-pass compiler so we don't need to Declare procedures and include uncalled procedures, etc.

Posted: **Mon Mar 15, 2021 12:38 pm**

Is there any plan to include users in the early design stage (prebeta?) for testing the new compiler?

Posted: **Mon Mar 15, 2021 12:39 pm**

BarryG wrote: If time is going to increase, you may as well make it a two-pass compiler so we don't need to Declare procedures and include uncalled procedures, etc.

The point is this is a backend, it's not a different compiler.
I don't think Fred has any intention of redoing it.

Posted: **Mon Mar 15, 2021 12:42 pm**

Fred wrote:- Inline ASM won't be supported directly at start. We plan to add naked ProcedureASM : EndProdecure which will create an assembly file, use fasm and link it to the final exe without needed to do anything

C support Inline ASM https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html
This is preferable, since fasm is not available for all platforms that GCC supports.

Cezary wrote:Is there any plan to include users in the early design stage (prebeta?) for testing the new compiler?

I have the same question.
If allow the community to test the current version, can quickly find bugs and take into account the community's advice, thereby making PB better.

Posted: **Mon Mar 15, 2021 1:52 pm**

BarryG wrote:
Fred wrote:- Compilation in release mode will be much longer
If time is going to increase, you may as well make it a two-pass compiler so we don't need to Declare procedures and include uncalled procedures, etc.

Only in release mode (when creating an exe), we still want to have the fastest Code/Compile/Test loop when you develop.

Posted: **Mon Mar 15, 2021 1:57 pm**

Selfish me, I scanned my code for pinch points:
With the C compiler and no inline ASM, how can I get the caller of a function?

Code: Select all

Macro GetCaller(me) ; Get struct pointer from caller
  CompilerIf #PB_Compiler_Processor = #PB_Processor_x64
    !mov [p.p_me], rbp
  CompilerElse
    !mov [p.p_me], ebp
  CompilerEndIf 
EndMacro

I have some speedup commands for Endian transfers, but C optimizers should match I hope?

Code: Select all

Procedure.w EndianW(x.w)
  ; ProcedureReturn (x & $FF) << 8 + (x >> 8) & $FF
  !MOV ax, word[p.v_x]
  !XCHG al, ah                ; Swap Lo byte <-> Hi byte
  !MOV word[p.v_x], ax
  ProcedureReturn x
EndProcedure

Posted: **Mon Mar 15, 2021 2:10 pm**

Fred wrote:
BarryG wrote:
Fred wrote:- Compilation in release mode will be much longer
If time is going to increase, you may as well make it a two-pass compiler so we don't need to Declare procedures and include uncalled procedures, etc.
Only in release mode (when creating an exe), we still want to have the fastest Code/Compile/Test loop when you develop.

Thank you, that is a good decision! It would be not good for the work flow, when you have to wait more than some seconds between start of compiling and seeing results.

@User_Russian: That do not looks like real ASM, just "templates" for c variables. I can not see the direct access to registers. EDIT: I am revising my statement, below it looks like I can use registers.

Posted: **Mon Mar 15, 2021 2:24 pm**

STARGÅTE wrote: Thank you, that is a good decision! It would be not good for the work flow, when you have to wait more than some seconds between start of compiling and seeing results.

Generally I agree, but the code you are going to test will not be the code you are going to release though.
For some class of programs (computational or real time like games) I would prefer to be able to select the slower but more realistic compilation.
Optimizations could introduce side effects, for example.
Or the lack of optimizations could make the test not indicative of how the program is going to actually run.

PureBasic Forums - English

Blog post !

Re: Blog post !

Re: Blog post !

Re: Blog post !

Re: Blog post !

Re: Blog post !

Re: Blog post !

Re: Blog post !

Re: Blog post !

Re: Blog post !

Re: Blog post !

Re: Blog post !

Re: Blog post !

Re: Blog post !

Re: Blog post !

Re: Blog post !