Compiler -- One more Pass

BackupUser · Post by **BackupUser** » Tue Feb 18, 2003 12:54 pm

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 !

BackupUser · Post by **BackupUser** » Tue Feb 18, 2003 5:17 pm

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...

BackupUser · Post by **BackupUser** » Tue Feb 18, 2003 5:45 pm

Restored from previous forum. Originally posted by fred.

We'll see.

Fred - AlphaSND

BackupUser · Post by **BackupUser** » Wed Feb 19, 2003 5:14 pm

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 !

BackupUser · Post by **BackupUser** » Wed Feb 19, 2003 7:19 pm

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.

BackupUser · Post by **BackupUser** » Wed Feb 19, 2003 11:39 pm

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)

BackupUser · Post by **BackupUser** » Thu Feb 20, 2003 1:31 am

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.

BackupUser · Post by **BackupUser** » Thu Feb 20, 2003 8:48 am

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

BackupUser · Post by **BackupUser** » Thu Feb 20, 2003 10:51 am

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)

BackupUser · Post by **BackupUser** » Thu Feb 20, 2003 1:24 pm

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.

BackupUser · Post by **BackupUser** » Thu Feb 20, 2003 1:35 pm

Restored from previous forum. Originally posted by Jose.

@Fred
Slower compiler not equal to slow app:)

BackupUser · Post by **BackupUser** » Thu Feb 20, 2003 5:28 pm

Restored from previous forum. Originally posted by fred.

Pupil is exactly right.

Fred - AlphaSND

BackupUser · Post by **BackupUser** » Thu Feb 20, 2003 6:01 pm

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)

BackupUser · Post by **BackupUser** » Thu Feb 20, 2003 11:02 pm

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

BackupUser · Post by **BackupUser** » Thu Feb 20, 2003 11:10 pm

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.