Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Modularize EEC into shared libraries #6

Open
SamuraiCrow opened this issue Jan 6, 2020 · 10 comments
Open

Modularize EEC into shared libraries #6

SamuraiCrow opened this issue Jan 6, 2020 · 10 comments
Labels
enhancement New feature or request
Milestone

Comments

@SamuraiCrow
Copy link
Contributor

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 SamuraiCrow added the enhancement New feature or request label Jan 6, 2020
@SamuraiCrow
Copy link
Contributor Author

#5

@SamuraiCrow
Copy link
Contributor Author

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

@SamuraiCrow
Copy link
Contributor Author

Superceded by #26 .

@SamuraiCrow SamuraiCrow added the duplicate This issue or pull request already exists label Jan 26, 2023
@SamuraiCrow
Copy link
Contributor Author

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

@SamuraiCrow SamuraiCrow removed the duplicate This issue or pull request already exists label Sep 20, 2023
@SamuraiCrow SamuraiCrow added this to the Release 1.0 milestone Sep 20, 2023
@SamuraiCrow SamuraiCrow reopened this Sep 20, 2023
@SamuraiCrow SamuraiCrow changed the title Modularize backends into shared libraries Modularize EEC into shared libraries Sep 20, 2023
@Hypexed
Copy link

Hypexed commented Sep 20, 2023

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
Copy link
Contributor Author

@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
Copy link

Hypexed commented Sep 22, 2023

@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
Copy link
Contributor Author

@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
Copy link
Contributor Author

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
Copy link
Contributor Author

#9 is identified as a prerequesite to this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants