PureBasic Forums - English

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.

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

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

What is the usecase ? To get the first parameter of an interface method ? You will have access to the whole C code, so it should be easy to pickup the right variable

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

Out of curiosity, I tried your inline ASM version VS normal PB version in C, and it's better in C as there is no more boilerplate code:

PureBasic x64:

Code: Select all

_Procedure0:
  MOV    qword [rsp+8],rcx
  PS0=48
  SUB    rsp,40
  p.v_x equ rsp+PS0+0
  MOV ax, word[p.v_x]
  XCHG al, ah                
  MOV word[p.v_x], ax
  MOVSX  rax,word [rsp+PS0+0]
  MOVSX  rax,ax
  JMP   _EndProcedure1
_EndProcedureZero1:
  XOR    rax,rax
_EndProcedure1:
  ADD    rsp,40
  RET

PureBasic C with /O2 (MSVC)

Code: Select all

f_endianw PROC
	movzx	eax, cx
	mov	edx, 255	
	shl	cx, 8
	sar	ax, 8
$end$4:
	and	ax, dx
	xor	ax, cx
	ret	0

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

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

There is a new compiler directive to control optimization from code: 'EnableCodeOptimizer' which will turn on the optimizer for C, like it will be in release mode. So you could use this combined with a CompîlerIf #PB_Compiler_Debugger = #False and you should be set to test easily you code without having to create an executable

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

Fred wrote: There is a new compiler directive to control optimization from code: 'EnableCodeOptimizer' which will turn on the optimizer for C, like it will be in release mode.

That's great!
Will it be be a global flag or you can do it for a section of the code like with EnableDebugger/DisableDebugger ?
In any case it's just great to have it.

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

luis wrote:
Fred wrote: There is a new compiler directive to control optimization from code: 'EnableCodeOptimizer' which will turn on the optimizer for C, like it will be in release mode.
That's great!
Will it be be a global flag or you can do it for a section of the code like with EnableDebugger/DisableDebugger ?
In any case it's just great to have it.

It's like EnableDebugger, in the code (there is no DisableCodeOptimizer because it works at the C compiler level)

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 !