tinygo
tinygo copied to clipboard
tinygo-org
gameboy-advance#8: Add -extra flag to tinygo command for adding .s files to compile step
I'm working on a codegen to build .s files (because they compile much faster and can have section names embedded) out of static assets for GBA ROMs, and this change allows specifying the path to these on the tinygo command-line.
@aykevl perhaps this commit is general useful not just for GBA development? I vaguely recall doing something similar when trying to compile some Cgo code?
I think something like this might be in TinyGo now? @aykevl can confirm.
No, this is not yet supported.
I think it would be nice if this is implemented not with an -extra flag but by accepting multiple "package names" during the build, and if they are a file and end in .c or .s (or other supported extensions) are included in the build.
Would it be appropriate to extract some of the files from this PR into a new PR to update the GBA machine package (for batter IORegs and Interrupt support)? It seems like the entry changes for ISR trampoline is a good addition too...
I noticed there is an open PR https://github.com/tinygo-org/tinygo/pull/861 for doing something similar. The design approach is nice, however the code generation for registering interrupts is an odd choice since it hides functionality. How do you think the overlap between these two PRs should be handled?
I am currently using the dev branch with files from this PR, namely
taking src/runtime/runtime_arm7tdmi.go
taking src/machine/machine_gameboyadvance.go
and using targets/gameboy-advance/entry.s for targets/gameboy-advance.s
It is working very well for me.
I noticed there is an open PR #861 for doing something similar. The design approach is nice, however the code generation for registering interrupts is an odd choice since it hides functionality. How do you think the overlap between these two PRs should be handled?
Yes, it's one or the other. The interrupt support in #861 uses a different implementation, see https://github.com/tinygo-org/tinygo/issues/515#issuecomment-573787597 for more information.
Interrupts are intended as a low level primitive, most user code should not be too concerned with them: in the future, higher-level Go-style wrappers should be used for peripherals such as the display.
While most compilers try to leave interrupts alone as much as possible, I have the opinion that making the compiler aware of interrupts can help to make them both efficient and flexible (something that would otherwise be hard to achieve on a platform such as the GBA). However, if you think this is not a good idea I'd like to hear why.
Closing since this is so far out of date.
Please see https://github.com/tinygo-org/tinygo/pull/3670 and https://github.com/tinygo-org/tinygba for where the GBA action is these days. Thanks for originally helping get this started @kylelemons