Comments (6)
The main problem I've ran into with C macros is that they're not great at doing arithmetic; one could, of course, leave the arithmetic part to lld
, but this would probably scale up to subtly impacting linking performance at the scale of hundreds of sections.
I'm going to lobby towards standardizing on Lua (which is an LLDB dependency regardless, alongside Python - though it may be optional...), but I will fully admit that I am unusually biased here as a long-time Lua enthusiast.
from llvm-mos-sdk.
(I'm willing to do some work on cleaning up the scripts in case they were to become an actual part of the SDK compilation process and not just a leftover from my work committed for preservation's sake.)
from llvm-mos-sdk.
The main problem I've ran into with C macros is that they're not great at doing arithmetic; one could, of course, leave the arithmetic part to
lld
, but this would probably scale up to subtly impacting linking performance at the scale of hundreds of sections.I'm going to lobby towards standardizing on Lua (which is an LLDB dependency regardless, alongside Python - though it may be optional...), but I will fully admit that I am unusually biased here as a long-time Lua enthusiast.
This is a good point; it would also matter whether the arithmetic expressions we could generate from the preprocessor would be gibberish or readable and meaningful. I'd take that as an additional success criteria: the generated output may be much more verbose, but it should be as clear as the input linker script.
The main advantage to a macro language over a generator is the ability to mix abstractions into the unabstracted source text. The generated output is implicit in a generator; in a macro language, one can pretend that it's just a linker script, but with function definitions. I'd argue that our linker scripts are still mostly linker scripts, and that's the ideal level of abstraction to work at. That is, if you actually could define a function in LD to generate a section definition given some input arguments, doing math and so forth, it would be pretty clear that that's the way to go, but que sera.
I do doubt that we'll seriously stress LLD with our tiny embedded platform though; the bits of the linker script parser I've read are pretty efficient Dragon Book stuff, and our linker scripts are similar in size to those I've seen from other embedded projects in the wild (amazingly). It is the case that the smaller the project, the bigger the linker script, though; so this is one case where we can't do anything crazily n^2.
from llvm-mos-sdk.
We could import a simple templating library if you want to use Lua like .PHP. macros, think pl.template or something even more self-contained.
from llvm-mos-sdk.
Was thinking about that; the main advantage of the C preprocessor at that point is that it's familiar and doesn't add a new dependency (we can use the one in llvm-mos clang). That may very-well be outweighed by other concerns; particularly lack of a looping construct seems likely to be fatal now that I think more on it.
from llvm-mos-sdk.
LISP! LISP ALL THE THINGS!
from llvm-mos-sdk.
Related Issues (20)
- [NES] Separate out `.aligned` section HOT 2
- Optimizing a faster isdigit() HOT 1
- Erroneous errors for null pointer derefs on Commander X16
- Assembling invalid 6502 op-code without error message. HOT 2
- Providing programmatic access to program length HOT 1
- Broken links for file that has a filename that begins with an underscore
- ARM64 macOS binaries HOT 6
- cx16 kernal name confusion: cx16_k_savehl vs cbm_k_savehl HOT 5
- PCE: pce_joypad_read() only returning low nibble? HOT 4
- atari8-stdcard "--whole-archive linking" regression
- bitrot in wiki porting page HOT 2
- Trying to define a smaller MMC3 ROM results in a wrong sized output HOT 1
- MMC3 IRQ setup doesn't work "out of the box"
- Add new platform(s): Foenix F256 Jr & K HOT 5
- Separate out SDK test workflow from packaging
- start address is indeterminate (because of zp data section)? HOT 1
- Write a simplified libretro runner
- Complete the libc using pieces from pdclibc HOT 1
- Investigate making `text.fixed` for libcalls
- Automatically generated linker scripts lack CMake integration HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from llvm-mos-sdk.