MAL implementation in Modula-2. #731
Conversation
This implementation uses the GNU Modula2 compiler and it runs all sets and test suites. Dockerfile is availabe for systems without a gm2 compiler. The implemention was harder than I expected. I worked with modula-2 twice in my early jobs. And I have fond memories of it. This work has also served as a reminder of those early days when everything was yet to be built, and we reinvented the wheel continously. Summary ------- * All steps implemented, Pass all tests. * Do not use modula2 ALLOCATE, details below. * Do not have a garbage collector. GM2 Compiler ------------ Having a GM2 compiler was the key enabler of this implementation, furthermore it includes the PIM and ISO libraries. I realized there was a modula-2 compiler two years ago, despite it have been available for more than ten years. Knowing the compiler was available, the only remaining challenge was finding enough time to dedicate to the project. GM2 ALLOCATE/NEW ---------------- 50% of the project was fighting with the ALLOCATE/NEW to reserve memory. It's slow. ALLOCATE / NEW also tracks every reserved object in a list. Some of the steps make heavy use of dynamic memory, and the ALLOCATE is really slow due to the objet tracking management. By step 5 i give up, and started using malloc. It was soo slow that the TCO test timeout despite the tail call optimization was workin was working.. Garbage collector ----------------- I intend to implement a Garbage Collector (Mark-and-Sweep or Cheney-style copying), if I can allocate additional time. Run Suite --------- $ make "docker-build^modula2" $ make DOCKERIZE=1 "test^modula2" Thanks ------ Obviously this implementation wasn't posible without the work of Niklaus Wirth and Gaius Mulley.
|
Hi @zawaza-blog. Sorry for the slow reply (work, travel, holidays, etc). Can you please add your implementation to |
- step2. input/output error. - stepA. EVAL checked HasError() but not HasException() in recursive calls, throw didn't stop evaluation.
|
Hi @kanaka I'm really grateful you have find time to look to the pull requests. The modula2 implementation has been added to IMPLS.yml, and the issues triggered in the self-hosted CI had been solved. |
kanaka
left a comment
kanaka
left a comment
There was a problem hiding this comment.
@zawaza-blog Looks good. One inline comment that needs to be fixed before I merge it.
impls/mal/run
Outdated
| MAL_FILE="../mal/stepA_mal.mal ${MAL_FILE}" ;; | ||
| esac | ||
| exec ./../${MAL_IMPL:-js}/run ${MAL_FILE} "${@}" | ||
| exec ./../${MAL_IMPL:-modula2}/run ${MAL_FILE} "${@}" |
There was a problem hiding this comment.
I think you accidentally changed the mal run script to use modula2 by default. You shouldn't need to do this. If you run make MAL_IMPL=modula2 test^mal that should run the tests is self-host mode using the modula2 implementation as the host implementation. The "js" here is just the fallback if you don't specify MAL_IMPL.
There was a problem hiding this comment.
Ops. Sorry. default MAL_IMPL has been reverted to "js".
Thanks again for your time and dedication. 😃
|
Hi @zawaza-blog. I'm requesting a couple more changes after reviewing the code in more detail:
|
|
Of course 😃, I will try to find some time to align steps 8 and 9 with the current approach of macroexpansion. |
- step8, step9 & stepA
* Removed the early macro expansion in eval.
* Changes to function application.
- First evaluate only the first element. Shall be a function.
- If function^.isMacro, apply it to unevaled arguments and update ast.
- Else evaluate remaining ast and apply the function.
- Removed the env & cache debug at the end of step5
|
Finally, I found spare time to implement the macroexpand current approach. It was fun. 😄 Changes done
|
2 participants
This implementation uses the GNU Modula2 compiler and it runs all sets and test suites. Dockerfile is availabe for systems without a gm2 compiler.
The implemention was harder than I expected. I worked with modula-2 twice in my early jobs. And I have fond memories of it. This work has also served as a reminder of those early days when everything was yet to be built, and we reinvented the wheel continously.
Summary
GM2 Compiler
Having a GM2 compiler was the key enabler of this implementation, furthermore it includes the PIM and ISO libraries.
I realized there was a modula-2 compiler two years ago, despite it have been available for more than ten years. Knowing the compiler was available, the only remaining challenge was finding enough time to dedicate to the project.
GM2 ALLOCATE/NEW
50% of the project was fighting with the ALLOCATE/NEW to reserve memory. It's slow. ALLOCATE / NEW also tracks every reserved object in a list. Some of the steps make heavy use of dynamic memory, and the ALLOCATE is really slow due to the objet tracking management. By step 5 i give up, and started using malloc. It was soo slow that the TCO test timeout despite the tail call optimization was workin was working..
Garbage collector
I intend to implement a Garbage Collector (Mark-and-Sweep or Cheney-style copying), if I can allocate additional time.
Run Suite
$ make "docker-build^modula2"
$ make DOCKERIZE=1 "test^modula2"
Thanks
Obviously this implementation wasn't posible without the work of Niklaus Wirth and Gaius Mulley.
Pull request requirements:
the implementation name.
Additional requirements if you are adding a new implementation (see FAQ for details):
impls/<IMPL>/Dockerfileimpls/<IMPL>/MakefileIMPLS.ymlMakefile.implsREADME.md