instead of improving the compiler myself, I just concentrate on developing a PB->FB translator and requesting the following basic features for easier translation:
DATA inside functions should be allowed
The label referring to this data doesn't pollute the global scope and some older compilers allow this feature.
dim ... as shared ... should be allowed in functions too
The idea behind this is that you can define a variable at global scope but only import it into several functions/subs. Some older compilers allow this feature too.
dim ... as local ...
The main purpose for using this storage modifier is that you can force a variable to be local to the function even if a variable of the same name was defined as shared at the global scope. Some older compilers allow this feature too.
GNU-style asm statement
This allows to specify the kind of registers for input and output values. It also allows you to define the clobbered registers which is very useful for the back-end.
FRAC function should be added
Returns the fractional part of a number. Is defined as x - fix(x).
dim ... as static ... should be allowed at global scope
In older BASICs, the arrays are always created on the heap. The declaration of an array as "static" indicates that the array should be placed into the .bss section instead. When the array is allocated in the .bss section anyway, the "static" should be simply ignored.
This are the first things that pop into my mind ... maybe I run into more of them soon.
1) Doable, DATA's end up in data sections anyways.
2) Won't be added, its against my religion, i'm tired to add hacks to the symbol-table, sorry.
3) Local variables can have the same name as globals when DIM'ed already, ala in C and unlikely in QB (where only function parameters could have the same name as globals).
4) A mini assembly parser would be needed for each platform the compiler may get ported to, can't add it myself, anybody is free to try..
5) Non-dynamic arrays at module-level are always static, no heap is used nor will. If not explicitly initialized, they are allocated in the bss section, taking (almost) no executable's space.
v1ctor wrote:2) Won't be added, its against my religion, i'm tired to add hacks to the symbol-table, sorry.
Hmm ... okay, this makes it impossible to use this compiler as a drop-in replacement for PB. Rewriting the sources is required :^( ...
v1ctor wrote:4) A mini assembly parser would be needed for each platform the compiler may get ported to, can't add it myself, anybody is free to try..
Um ... I'm somewhat confused ... replacing all input/output values with the right registers is such a simple task, this can be done with sed ... or do you mean the "right" register selection for the input/output values (on assembler block entry/exit)? This might be somewhat more complicated when you want to optimize the sources ;).
i don't understand this need for a pb drop in replacement. is it to much to ask for people to simple modife there code or learn somthing new ?
FB doesn't fully support the QB communty becasue it was never ment to be a drop in replacement just a BASIC compiler that match it's syntex not a clone. the same goes with PB i don't think we should have to well accomidate the main distro for PB users.
the simple fact is victor can't simple change FB everytime some one from a different basic dialect wants somthing different because to do so would Πss of another faction with in the FB communy for example lets say victor complete PB FB for you this would really tick off the QB faction of the FB communty which is well the majority. but it will also get the few RapidQ people mad and other from other dialects as well.
as it stands FB been pretty much canonized people are use to it's syntex stly and the way things works maybe 4 or 5 month ago change could have been accepted but not now outside changes to fix bugs and upgrade to the language the way victor has already layout.
so if you really want a PB FB simple fork the project which is your right since it's opensource.
Shadowwolf wrote:i don't understand this need for a pb drop in replacement. is it to much to ask for people to simple modife there code or learn somthing new ?
Never change any of your sources if you don't have to.
Shadowwolf wrote:FB doesn't fully support the QB communty becasue it was never ment to be a drop in replacement just a BASIC compiler that match it's syntex not a clone. the same goes with PB i don't think we should have to well accomidate the main distro for PB users.
I understand this but currently the compiler lacks some important features that make porting older applications an enormous (and useless) task.
Shadowwolf wrote:the simple fact is victor can't simple change FB everytime some one from a different basic dialect wants somthing different because to do so would Πss of another faction with in the FB communy for example lets say victor complete PB FB for you this would really tick off the QB faction of the FB communty which is well the majority. but it will also get the few RapidQ people mad and other from other dialects as well.
Please be more friendly and avoid words like "Πss off"
When you read the previous messages from me then you should know that I already gave up my wishes related to direct PB compatibility.
Porting older sources might require some features that aren't implemented in FB (compiler or RTL) yet and asking for it should be OK.
Shadowwolf wrote:so if you really want a PB FB simple fork the project which is your right since it's opensource.
I really think about it ...
Regards,
Mark
PS: Being a bit more friendly would be nice. Thanks.
i'm not a blunt person most of the time. i know what the reaction people are going to have to the idea of somone trying to get FB turn in PB like clone. it will be the same reaction people had to people attamping to get rapidQ like concepts into FB.
also your argument for change still isn't convicing yes some code won't be easly ported from PB to FB but that not really the point nor the orignal goal.
FB is a BASIC compiler coming out of the QB community and it does show the signs of this wear QB code is very compatible with FB. it would show the same thing if FB was devople from the PB communty.
but at the same time FB has move beyound QB it maintain some backward compatiblity so QB code will run smoth on FB for the most part. but it is somthing of it's own now. and is devopling it own community around it.
so the real goal is not to try to get FB to become a great universal Basic compiler that would be crazy. it's to simple devople it own name and styl.
If it's a global variable then why does it matter if it's declared inside a function or out? Would it kill you to move the 10 lines of code in your program with an AS SHARED in the function?
jofers wrote:If it's a global variable then why does it matter if it's declared inside a function or out? Would it kill you to move the 10 lines of code in your program with an AS SHARED in the function?
Never mind. I give up. FreeBasic is useless for porting existing PB code. However, it's a good tool to develop new software.
QB's SHARED never made any sense, but it was somehow needed as you couldn't have local variables with the same name as global ones (what is allowed in FB).
"SHARED foo(), bar" wasn't supported since day one, as that would need some stupid hacks in the symbol-table and because you can't find that inversion of scope "feature" in any other languages (that i know of) than in some versions of BASIC, what would make things even more complex with classes, SHARED what? Inside the class only? The whole module? The land of confusion (omg, Genesis, nooo)..
PB (the Windows one) introduced some of the ugliest syntax-sugars i ever saw like "SHIFT LEFT abc, 1", "CALL DWORD foo USING bar TO res" and other no sense constructions like that, i don't see why everything must be a statement, i doubt a beginner would find it harder to use say "abc = abc shl 1" or "res = foo(bar)", but then it's just my opinion..
