How to Manage FB Reusable Procedures by Including Source Modules (vs. compiled modules)

Forum for discussion about the documentation project.
marcov
Posts: 2748
Joined: Jun 16, 2005 9:45
Location: Eindhoven, NL
Contact:

Re: How to Manage FB Reusable Procedures by Including Source Modules (vs. compiled modules)

Postby marcov » May 28, 2018 14:35

Josep Roca wrote:> I don't see what all this adds/improves, except making a proven solution slower.

1.- You get dead code removal without having to compile each separate procedure as an object file.


You don't have to do so now either, with section based smartlinking.

2.- You also get dead code removal with classes (types).


No change at all. The changes that you have to make to the compiler to discard unused classes are in the same code as to properly prepare them for sections based smartlinking (if not done already for FB)

3.- You can use conditional compilation and also macros.


Without that, you can do that too, it is just that you need to trigger a build in some cases (either due to a smart IDE or manually if you are a Paleo). And you get the compile speed advantages in all the cases where you just fix a typo.

4.- You don't need to rebuild libraires each time that you make a change. Since we are working with source code, just change it.


Then just force a build on every compile in the current system. Your solution will be about the same speed, so that doesn't matter.

5.- The same code works with 32 and 64 bit. No need to build separate libraries for both.


Same, just force a build. It will be slow, but you can clean everything out between builds to avoid state.

6.- No need for import libraries.


Well, first of all, separate import libraries are not needed at all, and most commercial compilers (and e.g. Free Pascal) generate what they contain them on the fly when linking. The fact that gcc needs them is a remnant of the first ports of Unix compilers to windows that got never really eliminated.

With modern computers, only the first time that you use the include files is the compilation a bit slower. Then, as they're in the caché, compilation is as fast as using libraries.


This is simply not true. Libraries are still much, much faster. Both because there is less I/O and directory searching needed, as well that the representation is read, parsed etc. Libraries are managed as arrays of sections that can be fixed up really cheaply. Easily hundreds of times faster as compiling the same source (and then the I/O bits are on top of that).

p.s. I realized that module in this context is a complex concept. A full module system (like e.g. Free Pascal)works also on language level, including errormessage generation, automatic recompilation on changes and namespaces,while a minimal compilation unit system (like C has) only works on linking level. For a descriptions just search for "module system" or "unit system" on this forum
Last edited by marcov on May 28, 2018 14:48, edited 1 time in total.
fxm
Posts: 8916
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: How to Manage FB Reusable Procedures by Including Source Modules (vs. compiled modules)

Postby fxm » May 28, 2018 14:40

We are not saying that this should replace the use of libraries.
We are just saying that this can be another way for user procedures reusing.

In addition, any comparison must be only done with the existing in FreeBASIC.
dodicat
Posts: 5703
Joined: Jan 10, 2006 20:30
Location: Scotland

Re: How to Manage FB Reusable Procedures by Including Source Modules (vs. compiled modules)

Postby dodicat » May 28, 2018 15:06

using my source code previously, with all functions public and creating a .a library
loading the static library, declare the function arcsinh, and print arcsinh(2) -- 32 kb.


using my source code previously, with all functions private
print arcsinh(2) -- 27 kb

both .exe's are stripped automatically by fb.
Josep Roca
Posts: 415
Joined: Sep 27, 2016 18:20
Location: Valencia, Spain

Re: How to Manage FB Reusable Procedures by Including Source Modules (vs. compiled modules)

Postby Josep Roca » May 28, 2018 15:13

> In addition, any comparison must be only done with the existing in FreeBASIC.

Quite right. What you can do or not with FreePascal is of not use to FreeBasic users. As I'm currently using FreeBasic and not FreePascal. I'm mainly interested in what I can do or not with FreeBasic.
dodicat
Posts: 5703
Joined: Jan 10, 2006 20:30
Location: Scotland

Re: How to Manage FB Reusable Procedures by Including Source Modules (vs. compiled modules)

Postby dodicat » May 28, 2018 15:32

I should mention that I used -gen gas previously.
-gen gcc produces similar sized .exe's (but not exactly the same)

I shall translate these functions to C, compile and strip the .exe -- later.
I don't have pascal.
fxm
Posts: 8916
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: How to Manage FB Reusable Procedures by Including Source Modules (vs. compiled modules)

Postby fxm » May 28, 2018 16:29

dodicat wrote:But you do expect some nit-picking when you present a page of reasoning?

That may be why there are not many volunteers to write such articles!
marcov
Posts: 2748
Joined: Jun 16, 2005 9:45
Location: Eindhoven, NL
Contact:

Re: How to Manage FB Reusable Procedures by Including Source Modules (vs. compiled modules)

Postby marcov » May 29, 2018 16:53

fxm wrote:
In addition, any comparison must be only done with the existing in FreeBASIC.


No it should not. Since what you require also requires work done on the compiler/assembler/linker system. So you should compare with a Free Basic that invested that same effort to improve the existing direction of the GAS backend.

And I simply use Free Pascal as a model for that (since they are similar in that they have their own (G)AS backends)

So in summary, I think changing the compiler to make it an easy to use source based system is more complex than perfecting the current library based solutions, and always will be slower for anything non-trivial.
fxm
Posts: 8916
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: How to Manage FB Reusable Procedures by Including Source Modules (vs. compiled modules)

Postby fxm » May 29, 2018 18:14

You have nothing to say in reaction to my last message?
fxm wrote:
dodicat wrote:But you do expect some nit-picking when you present a page of reasoning?

That may be why there are not many volunteers to write such articles!
I'm a little disappointed!
(though I think I'm right at least on this point)
fxm
Posts: 8916
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: How to Manage FB Reusable Procedures by Including Source Modules (vs. compiled modules)

Postby fxm » May 29, 2018 18:31

marcov wrote:
fxm wrote:
In addition, any comparison must be only done with the existing in FreeBASIC.


No it should not. Since what you require also requires work done on the compiler/assembler/linker system.

I do not understand.
This article requests no evolution/improvement on the compiler/assembler/linker.
It presents only another way of doing (than by libraries) that already works.
dodicat
Posts: 5703
Joined: Jan 10, 2006 20:30
Location: Scotland

Re: How to Manage FB Reusable Procedures by Including Source Modules (vs. compiled modules)

Postby dodicat » May 29, 2018 18:52

fxm.
Sorry, I didn't realise you were prompting for a reply.
I hadn't really thought about any particular topic.
What is the sense of making one just for the sake of it?
I would probably confuse the issue anyway.
Look at what just happened with private functions!

I didn't volunteer an MD5 for the wiki sign ups, I would have thought that any aspiring authors would emanate from that pool.

Marcov
I assume that the FreePASCAL 64 bit has the GAS backend also??
fxm
Posts: 8916
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: How to Manage FB Reusable Procedures by Including Source Modules (vs. compiled modules)

Postby fxm » May 29, 2018 19:21

dodicat wrote:fxm.
Sorry, I didn't realise you were prompting for a reply.

It was not directly intended for you, it was just to taunt marcov!
Josep Roca
Posts: 415
Joined: Sep 27, 2016 18:20
Location: Valencia, Spain

Re: How to Manage FB Reusable Procedures by Including Source Modules (vs. compiled modules)

Postby Josep Roca » May 29, 2018 19:43

> It presents only another way of doing (than by libraries) that already works.

And he is making assumptions without having tried it.

When I began to use this technique with PowerBasic, an user that mainly works with MASM and only uses PowerBasic for quick small utilities, strongly criticised it. After several years, he is still advocating the use of libraries from time to time, but nobody follows his advice and are using include files. The few that have written libraries for PowerBasic are third-party programmers that aren't willing to release the source code.
dodicat
Posts: 5703
Joined: Jan 10, 2006 20:30
Location: Scotland

Re: How to Manage FB Reusable Procedures by Including Source Modules (vs. compiled modules)

Postby dodicat » May 29, 2018 20:57

If you want your chosen language (PowerbASIC, FreePASCAL, FreeBASIC ...) to interact with the big wide world, then you are obviously library inclined.
I know that PowerBASIC was used to assist Visual Basic via compiled libraries, (It was part of it's advertising)
Apart from that I know very little about PowerbASIC, except that on the surface it seems similar to FreeBASIC, or maybe fblite.
Pascal probably doesn't need any help from FB or PB.(But I found their graphics (wingraph) a little jumpy).
marcov
Posts: 2748
Joined: Jun 16, 2005 9:45
Location: Eindhoven, NL
Contact:

Re: How to Manage FB Reusable Procedures by Including Source Modules (vs. compiled modules)

Postby marcov » May 29, 2018 21:05

dodicat wrote:I assume that the FreePASCAL 64 bit has the GAS backend also??


Yes and no. If you mean own internal backends, yes. While there are JVM and LLVM options in practice nearly everyone uses the native backend.

If you mean GAS, as not the backend, but actually using GAS as backend assembler, for the most, NO GAS is not default anymore since about 2007, starting with windows it was slowly replaced by own internal assemblers (built into the compiler). Some non-x86 targets still use as though.

The same goes for the linker, LD, but less progressed, it is internal for the more static targets (Dos and Windows), but Unix still uses LD.
Last edited by marcov on May 30, 2018 13:53, edited 1 time in total.
marcov
Posts: 2748
Joined: Jun 16, 2005 9:45
Location: Eindhoven, NL
Contact:

Re: How to Manage FB Reusable Procedures by Including Source Modules (vs. compiled modules)

Postby marcov » May 29, 2018 21:08

Josep Roca wrote:> It presents only another way of doing (than by libraries) that already works.

And he is making assumptions without having tried it.

When I began to use this technique with PowerBasic, an user that mainly works with MASM and only uses PowerBasic for quick small utilities, strongly criticised it. After several years, he is still advocating the use of libraries from time to time, but nobody follows his advice and are using include files. The few that have written libraries for PowerBasic are third-party programmers that aren't willing to release the source code.


If PB also couldn't do proper smartlinking, it is even sadder than I thought. Usually the commercial ones get this kind of stuff right.

As for FB technically there is no reason why it shouldn't work. It works for gengcc, and those use the same tools. FB probably only need to emit proper section headers to AS.

In ye old days, we compiled every symbol into a separate module in the library to make this work, but afaik that is no longer needed to day. (and it was dog slow, since as and LD were not very optimized for that). It was one of the reasons for migrating to internal as/ld.

Return to “Documentation”

Who is online

Users browsing this forum: fxm, MrSwiss and 1 guest