Still working on variadic functions, a bit harder that I thought but the release is coming soon.
robert wrote:Compiled and linked on Fedora 31 with the latest FreeBASIC 1.08 source from Github. No problems. Copied fbc_new as fbc64_gas64 to the install directory, replacing your GAS64 compilation and am now testing examples. No more ospeed warnings. So far ... so good.
What do you call ospeed warning ?
Any problem when compiling ?
What Github official or mine ?
Do you use the modified modules provided with in the zip file ?
In the link script you can change 'fbc_new' by 'fbc64_gas64' to directly have the right name.
D.J.Peters wrote:looks like your code emitter doesn't have any optimization stage right ?
Due to the way the instructions are sent to the emitter it's hard to do a strong optimization. For now just 'micro' optimization a posteriori on the generated code.
Example of instruction flow and micro optimization
Here a local variable ARGS is initialized to zero
first instruction : addrof --> retrieve its address
second instruction : memclear --> put zero at the address
Code: Select all
# Info --> addrof ARGS.3+-136 [any alias "va_list" ptr]
# Info --> v1=var ARGS ofs=-136 [any alias "va_list" ptr] symbdump=var local accessed declared ARGS [any alias "va_list" ptr]
# Info --> vr=reg 1 [any alias "va_list" ptr ptr]
#O4lea r11, -136[rbp]
# Info --> memclear vr1 [any alias "va_list" ptr ptr]
# Info --> v1=reg 1 [any alias "va_list" ptr ptr]
# Info --> v2=imm 8 [integer]
#O4mov QWORD PTR [r11], 0
mov QWORD PTR -136[rbp], 0 #Optim 4
The optimization is done after the code generation by 'analyzing' the last line with kept data from the previous one.
Maybe better is possible by analysing totality the functions, I have to look at the asm code and think a lot how it can be done. But I don't want to go upstream in the compiler : just staying in the emitter.
However current executables should run at same speed (or faster) than those gotten with gcc (without optimization flags.....).
A way to do if speed is an issue : keep the asm code, look at it and just handly optimize the critical part with inline asm in the basic code.
Another of my goals is to be able to debug as with gas32. With gcc there are too much changes in code and variables therefore debugging could be hard. In this case speed doesn't matter.
Lost Zergling wrote:I did some tests because the project seemed really interesting to me.
Thank you for your real interest, repeated 3 times :-) Comments are welcome.
- The compilation seems to no longer work beyond a certain volume of code (w10, 64), and it's really a problem of size (too many function calls in the same scope?): Apparently it's a real size problem and nothing else (I copied pasted different blocks of code to make sure). From my point of view, it is blocking due to the maintenance of overloaded programs.
Not sure to understand. Could you send me examples, commented in french ;-) d eb ug @ alice adsl .fr (no space)
- I am not at all an assembly language expert, but there are alternatives in terms of license (FASM, BSD copyleft) or NASM (BSD): this could provide an effective alternative and therefore an additional interest compared to gcc.
Could you explain more the advantages ? For me here the assembler is 'only' a translator the important 'job' is done before.
- It seems to me desirable that you further specify the license for your work.
I'm not very aware about licensing. As it's just a new module in fbc and some light modifications somewhere else it should follow freebasic's one.