Page 2 of 3
Posted: Tue Feb 18, 2003 12:54 pm
by BackupUser
Restored from previous forum. Originally posted by theogott.
I would definitely prefer a "multi-pass system".
Compile-time is not a factor on modern PC Systems.
I know old Powerbasic-Compilers wrote after compilation "199000 Lines per second."
However if that would be an argument for a product then microsoft would
have been added it to VB.
One second morte or less in compile-time is only intresting for "Trial-and-error"
programmers. If you plan your programm and sort the procedures, a intelligent-multipass-compiler
is the thing of your choice.
Btw. FASM has GREAT MAcro-Features. Does anyone know how they can be used from Purebasic ?
The Help-File I have here seems to cover less then 25% of what can be done REALLY with this newer version.
*************************
The best time to do things is now !
Posted: Tue Feb 18, 2003 5:17 pm
by BackupUser
Restored from previous forum. Originally posted by ricardo.
Originally posted by Franco
Hi guys,
that's why I like to have the possibility to create Purebasic libraries with PureBasic itself (and ask for over a year now for it...)
I second this wish.
Many of us has some functions that could be nice to compile as lib.
Maybe this libs are not high optimized asm but... if i put this function as a lib or as code in my app however its not high optimized asm, no difference.
Of course the best idea is to have a different folder for the own coded libs.
Fred, are you agree?
Best Regards
Ricardo
Dont cry for me Argentina...
Posted: Tue Feb 18, 2003 5:45 pm
by BackupUser
Restored from previous forum. Originally posted by fred.
We'll see.
Fred - AlphaSND
Posted: Wed Feb 19, 2003 5:14 pm
by BackupUser
Restored from previous forum. Originally posted by theogott.
Thats my biggest problem with Powerbasic.
Once talking about that in the Powerbasic-Forum, they could not understand WHY
it makes sense to let the compiler himself "leave out" unused procedures (like Purebasic can do, Powerbasic can't).
A good programming system must be able to have a big library with often (and seldom) used functions and you just include them when you need them.
And when you don't need them, they should not waste space in your code.
For me thats easy to understand.
*************************
The best time to do things is now !
Posted: Wed Feb 19, 2003 7:19 pm
by BackupUser
Restored from previous forum. Originally posted by Pupil.
> Once talking about that in the Powerbasic-Forum, they could not understand WHY
> it makes sense to let the compiler himself "leave out" unused procedures
> (like Purebasic can do, Powerbasic can't).
PureBasic can't leave out Procedures if they're not used, it's pretty hard to make something like this with a one-pass compiler, but if Fred makes PB a two-pass compiler that sort of stuff is much simpler for him to implement. What PB does at the time being is that, if the Pure Libraries is splitted, only the code for the actual commands used in your program is included in the final EXE.
Posted: Wed Feb 19, 2003 11:39 pm
by BackupUser
Restored from previous forum. Originally posted by tinman.
Originally posted by Pupil
PureBasic can't leave out Procedures if they're not used, it's pretty hard to make something like this with a one-pass compiler, but if Fred makes PB a two-pass compiler that sort of stuff is much simpler for him to implement.
Just a reminder to Fred that simply cutting out uncalled procedures might not always be a good idea (for the same reason about the Return without Gosub stuff). You may not always call all of your procedures directly. Making it optional would be best (or being able to specify that a procedure is safe to remove?).
--
It's not minimalist - I'm increasing efficiency by reducing input effort.
(Win98first ed. + all updates, PB3.51, Ed3.53)
Posted: Thu Feb 20, 2003 1:31 am
by BackupUser
Restored from previous forum. Originally posted by PB.
> cutting out uncalled procedures might not always be a good idea
> (for the same reason about the Return without Gosub stuff).
No, it's not the same: a procedure, if uncalled, won't affect the rest
of the program in any way. It's fully invisible if uncalled, whereas
an uncalled Gosub routine isn't.
Posted: Thu Feb 20, 2003 8:48 am
by BackupUser
Restored from previous forum. Originally posted by fred.
Ok, all is sensitive and I will probably make a quickly first pass, even it will slowdown the compile time. Not for next version tough.
Fred - AlphaSND
Posted: Thu Feb 20, 2003 10:51 am
by BackupUser
Restored from previous forum. Originally posted by tinman.
Originally posted by PB
> cutting out uncalled procedures might not always be a good idea
> (for the same reason about the Return without Gosub stuff).
No, it's not the same: a procedure, if uncalled, won't affect the rest
of the program in any way. It's fully invisible if uncalled, whereas
an uncalled Gosub routine isn't.
Code: Select all
ProcedureDLL whats_gonna_happen_here(foo.l)
; Do stuff
EndProcedure
That procedure is never called, but you can be sure that if Fred simply cuts out uncalled procedures then things are going to screw up. Also:
Code: Select all
Procedure foo(bar.l)
; Do stuff
EndProcedure
CallFunctionFast(@foo(), $DEADBEEF)
It's not called directly, so again you can't simply hack out the procedure because "foo($BAADC0DE)" does not appear in your source.
--
It's not minimalist - I'm increasing efficiency by reducing input effort.
(Win98first ed. + all updates, PB3.51, Ed3.53)
Posted: Thu Feb 20, 2003 1:24 pm
by BackupUser
Restored from previous forum. Originally posted by Pupil.
@tinman
Your first example is a valid one, ProcedureDLL's should be treated differently from oridinary Procedures. Your second example though is a bit flawed. As all can see there is indeed a reference to the procedure in the code so the compiler would know that it shouldn't skip that particular procedure, at least that is how i imagine the compiler must work.
Anyway, ultimately it's up to Fred how he plan to implement the thing.
Posted: Thu Feb 20, 2003 1:35 pm
by BackupUser
Restored from previous forum. Originally posted by Jose.
@Fred
Slower compiler not equal to slow app:)
Posted: Thu Feb 20, 2003 5:28 pm
by BackupUser
Restored from previous forum. Originally posted by fred.
Pupil is exactly right.
Fred - AlphaSND
Posted: Thu Feb 20, 2003 6:01 pm
by BackupUser
Restored from previous forum. Originally posted by tinman.
Originally posted by Pupil
a bit flawed. As all can see there is indeed a reference to the procedure in the code so the compiler would know that it shouldn't
My point in the second example was that it is simply not a case of cutting out uncalled procedures (its not called, but it is referenced). There are probably other ways to achieve the same effect that should also be watched out for, e.g.
! call p_foo
(again the procedure is referenced, but will PB handle that properly if all ! lines are passed directly to the assembler).
--
It's not minimalist - I'm increasing efficiency by reducing input effort.
(Win98first ed. + all updates, PB3.51, Ed3.53)
Posted: Thu Feb 20, 2003 11:02 pm
by BackupUser
Restored from previous forum. Originally posted by Pupil.
Well it's tricky to exactly know where to draw the line, how advanced exclusion algorithm to use? An algorithm can only be that smart and still remain fast and non-bloated. There are lots of circumtances that can occur that will display weaknesses of different approaces. For instance look a this simple example:
Code: Select all
Procedure.l Proc1(a.l)
ProcedureReturn (a+Proc2(a))
EndProcedure
Procedure Proc2(b.l)
ProcedureReturn b>>4|$80
EndProcedure
End
Here we have a procedure calling another procedure i.e. 'Proc2' is referenced once, but the calling procedure (Proc1) isn't referenced in the main code so this part is cut out. Now the compiler have to somehow know that the refering code is cut out and there is no longer a valid reference to Proc2 and cut out that part too.
When you add up all the different methods of calling procedures all this could build up to quite a hefty piece of code, one which i don't think the effort put into it is really worth the gain.
Well that was just some stray thoughts from my side, as to your argument tinman, which is a valid one; for the compiler to be able to cope with that kind of call the compiler would have to process ALL direct ASM lines to check for any referenceses to a procedure.
Guessing what would work and not work is to no gain as PureBasic hasn't got this feature at the moment, the compiler will handle all the situations Fred programs it to handle and hopefully he'll include a switch to turn the feature off too. When/if Fred has/will inluded/include this feature we'll all be happy to point out, in the bug report section, in which situations it doesn't work
Posted: Thu Feb 20, 2003 11:10 pm
by BackupUser
Restored from previous forum. Originally posted by PB.
> Here we have a procedure calling another procedure i.e. 'Proc2' is
> referenced once, but the calling procedure (Proc1) isn't referenced
> in the main code so this part is cut out.
I don't know what's so hard about making the compiler leave out any
unreferenced procedures... my own PBToolBox app has had a feature for
ages which tells you which procedures are unused (unreferenced) so you
can manually remove them. Unfortunately I don't support/update that
app anymore as I've lost interest.