Got an intersting Info today, that i want to share.
Its about the GOSUB issue that regular PureBasic does not allow GOSUB in Procedures.
There is some sort of Workaround
- FASM-Gosub Replacement (http://www.purebasic.fr/english/viewtopic.php?f=12&t=55242).
- and this "Call Macros" (http://www.purebasic.fr/english/viewtopic.php?f=12&t=49782)
QuoteThe issue with the gosub implementation in procdures perhaps was due to the single pass
compilation, the specific issue would arise from select statements where PureBasic uses the stack
so when either a gosub or goto is used to exit from within a select statement it will either result in
reading the wrong local variables or produce an IMA on returning from the procedure.
So It appears Fred disallowed gosub within procedures.
I've provided macro replacements for goto and gosub with FASM preprocesor directives
to handle this issue, you just need to use a depth parameter if you're exiting a select
Must admit that it still looks a bit complicated to me compared to PowerBasic.
But if it works ...
pure solution in powerbasic :)
Function PBMain () As Long
Local i As Long
For i = 1 To 3
! jmp lbl_show
lbl_ret:
Next i
Exit Function
lbl_show:
? Str$(i)
! jmp lbl_ret
End Function
'
' and these macros
'
Macro p_return (lbl)
! jmp lbl_ret
End Macro
Macro p_gosub (lbl)
! jmp lbl_show
lbl_ret:
End Macro
Thats a poor sollution, Aslan :-) because using CALL you can use the Macro more then once and the return adress is saved.
Did you take a look on both solutions?
In Powerbasic its simpler as you know (http://www.jose.it-berater.org/smfforum/index.php?topic=277.0).
They are good indeed, somehow complicated. I just don't understand the reason of why gosub wans't implemented.
There is something else rather than 'due to single pass compilation...'.
Powerbasic is single pass compiler too, but does a lot.
I suppose, internal Purebasic to fasm translator is not that complex and smart as it should be from the first sight.
> Powerbasic is single pass compiler too
Wrong. it is a three pass compiler.
Quote from: Aslan Babakhanov on October 21, 2013, 10:28:15 PMPurebasic to fasm translator is not that complex and smart as it should be from the first sight.
Long ago, there was a third-party optimizer for PureB that would optimize the ASM it generated.
Over the years, most of the optimization by Fred
seems to have been in the libs as opposed to the compiler.
Quote from: José Roca on October 21, 2013, 10:39:48 PM
Wrong. it is a three pass compiler.
Jose, thanks for information.
I always thought, that PB is a single pass compiler (read on forum long time ago).
Don't believe all what you read. Older versions of the compiler where two-passes. A third pass was added in PB9 to handle forward references. Most "indie" basics, like Pure Basic and FreeBasic, are single pass, which is inefficient.
Some people say they are "enhanced MACRO Assembler Scripts" compared to the PB Compiler. PureBasic for example can not make a FOR Loop with something else then Integer Data. No
FOR I=0.001 TO 0.78 STEP 0.01
for that reason. Thats why i suggested in their wishlist thread a compiler modernization. In 32 bit compiling the PowerBasic Compiler is definitely 2 passes ahead.
Quote from: José Roca on October 22, 2013, 06:43:12 AM
Don't believe all what you read. Older versions of the compiler where two-passes. A third pass was added in PB9 to handle forward references. Most "indie" basics, like Pure Basic and FreeBasic, are single pass, which is inefficient.
I would argue that PowerBASIC has a more inefficient compiler than PureBasic. For PowerB to be a three-pass compiler and still produce the bloated EXEs it does not speak well for efficiency. The last two versions of PowerB saw significant bloat added as the mottoes "smaller faster" and "say goodbye to bloatware" were apparently abandoned.
Brice, you have wrong informations.
Compare the ASM Output, then you will see that in fact the output of the powerbasic compiler is better oprimized then the PureBasic Output.
For more details, take a look here:
PureBasic stack-based Compiler Output (http://www.purebasic.fr/english/viewtopic.php?f=7&t=54606&hilit=Single+Pass+Compiler)
and compare it with the equivalent of the PowerBasic 32 bit compiler.
The pure size of the smallest executabel depends on what sort of code you are doing and what runtime is included.
The size of a "Hello world" doesn't help so much if its within a range.
Having said this, i must add that the differences will be not noticeable in 99.9% of all normal usage cases.
Quote from: Theo Gottwald on October 22, 2013, 10:39:28 AM
Brice, you have wrong informations.
No, I don't. I am merely suggesting there is more than one way to look at the efficiency of a compiler.
What else do you look at, if not the ASM Output?
The IDE is definitely better with PureBasic (and it is multiplatform), and it has tons of more features.
But we are talking about the x32- Compiler-Core and about this PowerBasic is two evolution-steps ahead.
Tell me something PowerBasic x32 can not do, you can do with PureBasic.
I have told you several things here already that is possible with PowerBasic, that PureBasic can not do.
Its clearly understandable if you look into history.
When Bob took the "Turbo Basic" he started with something that was already an stable compiler.
That was created from people with university background on information technology.
Looking at PureBasic you can see that Fred started as some sort of "Hacker" and made an adventure building his first PureBasic.
At that time Fred just started. Just like Charles started his compiler.
They did not visit the university "on compiler building" before.
The knowledge on Compiler Technology was not there. He just did it. I have that old PureBasic versions still here.
Of course he improved step-by-step.
But i believe, if he would start "from scratch today" he would make something that would possibly have all that features.
But now he has the problem that you can not put "old constructs easily from top to bottom".
He would not make the thing " Stack based". Also VC is not "Stack based" in this way.
Quotemost of the optimization by Fred seems to have been in the libs as opposed to the compiler.
This is just the point. If i add some libs, i can say "Look Ma'm i have new FEATURES". If i optimize the compiler inside, it takes awful lots of time, and it sells rather bad.
Anyway, if you use Purebasic as some sort of "Brickbox", calling ready-made libs, you get most out of it.
And there are several libs that make life really easy, and make PureBasic the tool of choice.
To work with complicated data structures and make hi-speed stuff, currently i see PowerBasic ahead.
Gosub is very easy to implement, so the decision to leave it out of a compiler, is perhaps, political rather than technical :)
An inner function that can access all the parental-scoped variables would be a good replacement, and have the advantage of being able to return values. - I'm currently testing this idea.
PS:
OxygenBasic uses up to 8 passes and still counting - good for dumping redundant code as early as possible.
Quote, as dependence on a single operating system, restrictions in the inline assembler, limited graphics capabilities, higher development costs, longer development cycles,
The only restriction in PowerBasic that applies to me is the missing x64. The other points can be resolved with libraries. The inline Assembler is weaker then an FASM, anyway its good for most uses, and i wonder if you will need more.
Today i came to anotehr PureBasic speciality: Procedure Parameters.
In PowerBasic you can say "BYREF" or "BYVAL". For any Procedure or Function Parameter.
In Purebasic there is nothing like that. Some datatypes are by default BYREF and others are always BYVAL.
Of course it works, and you can solve your problems with it, but it does not have the completeness and elegance of PowerBasic. And i did not yet start with the PowerBasic string-engine or the COM implementation.
Of course this has needed a long developement time, yet this is not my problem.
About this PowerBasic can compete C-Language while PureBasic does not (yet) offer ALL the possibilities. At a closer look it looks more like a Toolbox - and thats nothing bad.
Its just not "state-of-the-art" in compiler science. If you would ask me whats a "state-of-the-art" sort of-compiler, i would recommend that you get the book "Metafont" and "TEX" from Donald Knuth.
This is "Information Technology" at its best.
@Charles, PureBasic has "Gosub". The Point is that it is forbidden inside Procedures, because there is a danger that it would leave an unbalanced STACK. For details you will need to look at the Links in previouse posts. Just from Speed a GOSUB/RETURN, that is in fact a single CALL/RET mnemonic, is unbeatable and i use it very often.
The code may not look so great - but its structured and fast.
About your Oxygen Basic: Using a lot of passes is a good idea, charles and shows that your compiler goes the right way. Of course it will resolve forward references.
With an inner gosub, there is always a risk of inadvertently falling into the body of the subroutine, but apart from that, the integrity of the stack would not be too hard to maintain.
Really i couldn't figure how, for a SDK programmer, PowerBASIC could be easier to translate to PureBasic rather than C++, i would like to understand that, because i have not attirance for sadomaso. 8)
Quote... The last two versions of (PowerBASIC) saw significant bloat added ...
I'm not sure "significant" is the right word here; what's a few bytes/kilobytes/megabytes in this day/age.
Patrice, its C that looks so far from Basic to me. But this is personal taste.
PureBasic also has the advantage that you can write a mail to the lead programmer (Fred) and he WILL give you an answer that helps. I like his behavior.
Quote from: Jim Dunn on October 22, 2013, 03:22:38 PM
I'm not sure "significant" is the right word here; what's a few bytes/kilobytes/megabytes in this day/age.
"Bloat because you can" is a lazy and shoddy programming methodology.
Quoteits C that looks so far from Basic to me
Not, when you are using the SDK coding style,
they are exactly the same!
Structurally, not exactly, Patrice :D
Structurally, a basic "Hello world" window, with a winproc callback and a message pump are exactly the same really. :)
Quote from: Patrice Terrier on October 22, 2013, 09:20:20 PM
Structurally, a basic "Hello world" window, with a winproc callback and a message pump are exactly the same really. :)
Yes, but later it looks like this:
; ListView.GetSubItemRect((INT) pHeader->nmcd.dwItemSpec, pHeader->iSubItem, LVIR_BOUNDS, &Position); ::)
and ... does it have a GOSUB?
GCC supports nested functions, with access to parent variables, a perfect substitute for gosub:
#include <stdio.h>
int main()
{
int a;
void mygosub()
{
a=42;
}
mygosub();
printf("%i",a); // 42
}
Charles,
Not my gcc
Quote
C:\CodeBlocks\Projects\nestes02\main.c|8|warning: ISO C forbids nested functions [-Wpedantic]|
James
Hi James,
My rig is a console-and-notepad job:
I compile direct with no switches : gcc gosub.c
It compiles to a.exe which is convenient for testing
Does it really compile to just 1 Mnemonic for CALL and one Mnemonic for RET?
Quote from: Charles Pegge on October 23, 2013, 01:30:24 PM
Hi James,
My rig is a console-and-notepad job:
I compile direct with no switches : gcc gosub.c
It compiles to a.exe which is convenient for testing
Charles,
I did a quick compile with code::blocks where I had the iso standard flag set hence the warning
It is a gcc feature.
James