dschmenk
commented
2 years ago Hi Steve-
Sorry for the late response, been off camping!
My memory is probably failing me and I have no recollection of this weakness in the PLASMA compiler. Which means it most certainly exists. I should look int this and fix it. I’ll check both the cross compiler and he self hosted compiler. Perhaps I even added a comment somewhere.
Dave...
On Jul 4, 2022, at 11:07 AM, ZornsLemma @.***> wrote:
Hi Dave, I hope you're well!
I hope this makes sense...
In C you'd often have a foo.h header which declares the functions and associated constants for code in foo.c, and then other code (in say quux.c) would do "#include "foo.h" to pick up those declarations. foo.c itself would normally #include "foo.h" as well, to avoid duplicating constant definitions and to consistency check the prototypes in the header with the actual code.
In PLASMA this technique doesn't seem to work. The attached zip file has a foo module with foo.pla and foo.plh files and a quux module which uses the foo module. When I compile this, the "foo" module ends up with a dependency on itself and the VM gets upset when trying to load it. (I have only tested the Acorn VM, to be scrupulously honest, but I can see from examining the "foo" module on disk that it does have a dependency on itself.)
I don't know how hard it would be to make this work. A necessary step would probably be to stop the compiler emitting a dependency when processing an import statement if the dependency is the module currently being compiled, but I don't know whether that would be sufficient or not.
I appreciate you may not have the time or inclination to look into making any code changes (although if you do that would be fantastic) but I'd appreciate your thoughts on this. Is it a reasonable thing to want, at least? Is it something you can already do if you just arrange things a little differently in the source code?
Thanks.
Steve
include-header-from-own-module.zip https://github.com/dschmenk/PLASMA/files/9041413/include-header-from-own-module.zip — Reply to this email directly, view it on GitHub https://github.com/dschmenk/PLASMA/issues/65, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABBOGJR6TSYBS6FQCFYF4RDVSMR6LANCNFSM52T4J7VA. You are receiving this because you are subscribed to this thread.
ZornsLemma
Hi Dave, I hope you're well!
I hope this makes sense...
In C you'd often have a foo.h header which declares the functions and associated constants for code in foo.c, and then other code (in say quux.c) would do "#include "foo.h" to pick up those declarations. foo.c itself would normally #include "foo.h" as well, to avoid duplicating constant definitions and to consistency check the prototypes in the header with the actual code.
In PLASMA this technique doesn't seem to work. The attached zip file has a foo module with foo.pla and foo.plh files and a quux module which uses the foo module. When I compile this, the "foo" module ends up with a dependency on itself and the VM gets upset when trying to load it. (I have only tested the Acorn VM, to be scrupulously honest, but I can see from examining the "foo" module on disk that it does have a dependency on itself.)
I don't know how hard it would be to make this work. A necessary step would probably be to stop the compiler emitting a dependency when processing an import statement if the dependency is the module currently being compiled, but I don't know whether that would be sufficient or not.
I appreciate you may not have the time or inclination to look into making any code changes (although if you do that would be fantastic) but I'd appreciate your thoughts on this. Is it a reasonable thing to want, at least? Is it something you can already do if you just arrange things a little differently in the source code?
Thanks.
Steve
include-header-from-own-module.zip