Modularize EEC into shared libraries

[SamuraiCrow]

Once shared libraries are possible put each backend in a seperate library and interface to the compiler as a single backend. Prerequisites: issue 5

[SamuraiCrow]

https://github.com/EEC-Developers/eec/issues/5

[SamuraiCrow]

Per opener libraries would be preferred to decouple the backends. The current library mode may be sufficient without a shared heap.

[SamuraiCrow]

Superceded by #26 .

[SamuraiCrow]

Reopening as a means of coordinating modularization using actual modules to break up eecmain.e as a stepping-stone toward library modules.

[Hypexed]

With this in consideration the compiler will then need a proper installer. Though it always needed the EModules assign modularising the compiler will mean it's split up into different system components it needs to load. Historically EC was composed of just one self contained binary file.

[SamuraiCrow]

@Hypexed It has always needed an installer and didn't have one. EBuild is a separate executable as is ShowModule. The original demo distribution of E 3.3a was a nightmare to navigate and an install script would have helped. E-VO has at least got a coherent collection of included modules.

Added to that, a modular compiler framework is easier to expand by adding different backends and ABIs to. AmigaE may never be cross-platform regardless of Chris Handley's attempt, but we should at least attempt to be system-friendly.

Issue #35 added.

[Hypexed]

@SamuraiCrow Like other compilers E needs it's assigns and commands added to path. Unfortunately fully modularising AmigaOS into config dirs was never completed after OS2 and so assigns and paths need to be manually added to start up files. The Installer way does not always guarantee a clean entry as it modifies a user script and it would have been better if they were added cleanly in their own dir. Even so I had to go through the fiddly process of setting E up. And yes, though useful, EBuild was a separate component like Explorer. It would be good to combine these into one package with even a simple installer. LIBS can be found from the program dir so modules can be kept together. Even a simple script can be in installer.

[SamuraiCrow]

@Hypexed The reason I want to make the backends into shared libraries is to keep the memory footprint to a minimum in preparation for the day that GCC13 can be an optional backend for E. Even though GCC can have a different parser for each compiler, I want to go the extra step of using the LibGCCJIT backend as a shared library so all Amiga compilers can have a good backend at once.

Of course having all that power will cost 32 megs of RAM so having the original backends will help as well. Ultimately, the core issue of loading in a PPC backend when you're compiling for 68k or vice versa means something has to change. As backends get bigger, they must also be modularly interchangeable.

[SamuraiCrow]

Since all code generators inherit from the codegen object in codegen.e, that would appear to be the starting place for this issue. Steps to make reentrant would include:

• making all globals into a context object
• making all "empty" methods into calls to a sublibrary
• addressing the ELF vs. Hunk format by putting those drivers into libraries also
• ???
• profit

[SamuraiCrow]

9 is identified as a prerequesite to this issue.