assembly: never say never!Fred wrote:But but but, they'll try to optimise our code with GASP assembly GASP
I'm sure some of them will come sooner or later, I'm not sure that now is the right time, I've already fallen victim to thinking inside the box a bit too much. I'm making a concerted effort to avoid that. They might be a bit too close to "how it's done" rather than "how it could be done".
When I was looking at memory structure trying to figure our how to setup memory.x at all, I was appalled to find stuff in there that fully isn't required and is misleading and just unused etc. I was expecting a nice modular clean set of files, instead I found Al's code modified and spread out not bad, but not good either. They should have started from blank. Or at least gutted it totally first. and put stuff back in selectively. IMO anyway.
I want them over here (though I doubt Ken will come) but not yet.
Fred.
here is what my prerequisites for assm code would be in our code:
1. Very small inline functions
2. pre and, post-conditions, purpose and usage cases are clearly and completely specified
3. the algorithm is documented as asm-specifics-independently as possible
4. asm code is completely documented with appropriately placed comments
5. the C equivalent of the asm code is available in the same function and switchable to with an ifdef (ready to be switched to C equivalent if the asm code is under suspicion or for other testing)
tell me about memory.x , i still don't understand much in theirs