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

Reply via email to