Blog post !
Re: Blog post !
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
- 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
Re: Blog post !
You may want to join the Discord Chat to ask questions.the.weavster wrote:Looks cool but I couldn't find a Get Started tutorialDanilo wrote:Beside BCX there is also Wonkey (github.com/wonkey-coders/wonkey) which translates to C++ and can import C and C++ libraries.
You need to write a module like the included modules (SDL2, GLFW, Sokol, pigpio, etc.)the.weavster wrote:And an example of importing C (preferably webview) would be very interesting
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.
Last edited by Danilo on Mon Mar 15, 2021 10:51 am, edited 1 time in total.
Re: Blog post !
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?
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?
PureBasic 6.04/XProfan X4a/Embarcadero RAD Studio 11/Perl 5.2/Python 3.10
Windows 11/Ryzen 5800X/32GB RAM/Radeon 7770 OC/3TB SSD/11TB HDD
Synology DS1821+/36GB RAM/130TB
Synology DS920+/20GB RAM/54TB
Synology DS916+ii/8GB RAM/12TB
Windows 11/Ryzen 5800X/32GB RAM/Radeon 7770 OC/3TB SSD/11TB HDD
Synology DS1821+/36GB RAM/130TB
Synology DS920+/20GB RAM/54TB
Synology DS916+ii/8GB RAM/12TB
-
- Addict
- Posts: 1443
- Joined: Wed Nov 12, 2008 5:01 pm
- Location: Russia
Re: Blog post !
I think that gosub can be abandoned.Fred wrote:we have trouble to implement GOSUB properly for example
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.Fred wrote:don't have any include file (flat .c file)
Re: Blog post !
Is compilation speed really so important? I only have small projects which never take then more than 3 seconds or something, usually less.
PureBasic 6.04/XProfan X4a/Embarcadero RAD Studio 11/Perl 5.2/Python 3.10
Windows 11/Ryzen 5800X/32GB RAM/Radeon 7770 OC/3TB SSD/11TB HDD
Synology DS1821+/36GB RAM/130TB
Synology DS920+/20GB RAM/54TB
Synology DS916+ii/8GB RAM/12TB
Windows 11/Ryzen 5800X/32GB RAM/Radeon 7770 OC/3TB SSD/11TB HDD
Synology DS1821+/36GB RAM/130TB
Synology DS920+/20GB RAM/54TB
Synology DS916+ii/8GB RAM/12TB
- the.weavster
- Addict
- Posts: 1537
- Joined: Thu Jul 03, 2003 6:53 pm
- Location: England
Re: Blog post !
With gcc compilers for other platforms too so we can cross-compile?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).
Re: Blog post !
Thanks for the additional info.Fred wrote:That's a lot of comments about the new back-end ! Let's clarify some points:
That's very nice to hear, especially for people who is currently investing in building something big enough with PB.- The x86-x64 asm compilers will still be supported, we don't have a plan to drop them at this point
Would be awesome to have both until the C backend has proven itself and there are no missing features or capabilities.
That's a nice feature.You could choose your compiler like you do when installing several version of PB)
Awesome- Inline C will be supported
It's still a nice way to do it considering the changes.- 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
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.- 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
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 look forward to those.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.
Last edited by luis on Mon Mar 15, 2021 12:36 pm, edited 1 time in total.
"Have you tried turning it off and on again ?"
A little PureBasic review
A little PureBasic review
Re: Blog post !
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.Fred wrote:- Compilation in release mode will be much longer
Re: Blog post !
Is there any plan to include users in the early design stage (prebeta?) for testing the new compiler?
Re: Blog post !
The point is this is a backend, it's not a different compiler.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.
I don't think Fred has any intention of redoing it.
"Have you tried turning it off and on again ?"
A little PureBasic review
A little PureBasic review
-
- Addict
- Posts: 1443
- Joined: Wed Nov 12, 2008 5:01 pm
- Location: Russia
Re: Blog post !
C support Inline ASM https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.htmlFred 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
This is preferable, since fasm is not available for all platforms that GCC supports.
I have the same question.Cezary wrote:Is there any plan to include users in the early design stage (prebeta?) for testing the new compiler?
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.
Re: Blog post !
Only in release mode (when creating an exe), we still want to have the fastest Code/Compile/Test loop when you develop.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.Fred wrote:- Compilation in release mode will be much longer
Re: Blog post !
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?
I have some speedup commands for Endian transfers, but C optimizers should match I hope?
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
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
The nice thing about standards is there are so many to choose from. ~ Andrew Tanenbaum
Re: Blog post !
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.Fred wrote:Only in release mode (when creating an exe), we still want to have the fastest Code/Compile/Test loop when you develop.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.Fred wrote:- Compilation in release mode will be much longer
@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.
Last edited by STARGÅTE on Mon Mar 15, 2021 2:26 pm, edited 1 time in total.
PB 6.01 ― Win 10, 21H2 ― Ryzen 9 3900X, 32 GB ― NVIDIA GeForce RTX 3080 ― Vivaldi 6.0 ― www.unionbytes.de
Lizard - Script language for symbolic calculations and more ― Typeface - Sprite-based font include/module
Lizard - Script language for symbolic calculations and more ― Typeface - Sprite-based font include/module
Re: Blog post !
Generally I agree, but the code you are going to test will not be the code you are going to release though.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.
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.
"Have you tried turning it off and on again ?"
A little PureBasic review
A little PureBasic review