On Thu, Jul 14, 2022 at 8:40 AM Philipp Klaus Krause <p...@spth.de> wrote: > > Am 14.07.22 um 13:24 schrieb Ralph Doncaster: > > It's used in a couple spots in ch554_sdcc > > https://github.com/Blinkinlabs/ch554_sdcc > > I've used it in a couple places in CMSIS_DAP > > https://github.com/nerdralph/ch554_sdcc/tree/master/examples/CMSIS_DAP > > > > It's a lot easier to use than gcc-style inline asm. The gcc inline > > asm rules with out: in: clobbers: labels are very complicated. > > I think the __asm ... __endasm form makes for cleaner looking code > > when optimizing individual functions into asm like I do here: > > https://github.com/nerdralph/ch554_sdcc/blob/master/include/debug.c#L119 > > Personally, I mostly put assembler code into separate C files. But where > I didn't, I also have used form 1 so far. > > Do you need support for preprocessor directives or macros in between > __asm and __endasm? I need to check the details, but I think that could > make a resonable compromise: it keeps backwards compability with most > inline asm in form 1, but also should most preprocessor vs inline-asm > issues. > > Philipp
I haven't been actively using SDCC in the past year, so my recollection may not be perfect. I seem to recall a couple situations where using the preprocessor was the only way I could get some optimized code to work. Maybe improvements to the linker related to code placement could help make up for that. _______________________________________________ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user