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 On Thu, Jul 14, 2022 at 7:59 AM Philipp Klaus Krause <p...@spth.de> wrote: > > SDCC currently supports two forms of inline assembler: > > 1: > __asm > asm code here > __endasm; > > and > > 2: > __asm("asm code here"); > > Form 1 requires some ugly hacks to avoid conflicts in the preprocessor. > I wonder if we could drop those, and maybe even change the keyword in > form 2 to __asm__. > > Does anyone rely on form 1 and would not want support for it dropped? > Any opinions on the possible rename of form 2? > > For comparison, GCC and clang both use: > > __asm__("asm code here"); > > as well as the following variants: > > * Using asm instead of __asm__ > > Which I think we do not want > > * __asm__("asm code here" : Output); > * __asm__("asm code here" : Output : Input); > * __asm__("asm code here" : Output : Input : Clobbers); > * __asm__ goto("asm code here" : Output : Input : Clobbers : Labels); > > These variants (which GCC allows in non-naked functions only) we might > want to support sometime (depending on user demand and SDCC developers > finding time to implement it). > > Philipp > > > _______________________________________________ > Sdcc-user mailing list > Sdcc-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/sdcc-user _______________________________________________ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user