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

[marcov]

> 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

[fxm]

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]

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]

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

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]

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]

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]

You have nothing to say in reaction to my last message?

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]

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]

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]

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]

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

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]

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.

[marcov]

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