Hello Philipp,
Thursday, July 14, 2022, 1:58:07 PM, you wrote:
NO!!!! Please, don't do that!
1. A lot of projects have bug chunks of assembly code in "form 1"
2. Allowing assembly-written naked functions is crucial
3. Separate assembly-only sources not always work well, because you loose
the ability to land it into the same object! For example, if you use
automatic banking and similar stuff, you loose ability to put assembly
beside the C code into the same bank.
This part is fine, why need do break it?
Your "improvements" will break the GBDK-2020 library.
There are still a lot of hacks beside that in SDCC, even more annoying, for
example, text-based PH rules. Why not enhance that instead?!
Thank you.
PKK> 1:
PKK> __asm
PKK> asm code here
PKK> __endasm;
PKK> and
PKK> 2:
PKK> __asm("asm code here");
PKK> Form 1 requires some ugly hacks to avoid conflicts in the preprocessor.
PKK> I wonder if we could drop those, and maybe even change the keyword in form
2 to __asm__.
PKK> Does anyone rely on form 1 and would not want support for it dropped? Any
opinions on the possible rename of form 2?
PKK> For comparison, GCC and clang both use:
PKK> __asm__("asm code here");
PKK> as well as the following variants:
PKK> * Using asm instead of __asm__
PKK> Which I think we do not want
PKK> * __asm__("asm code here" : Output);
PKK> * __asm__("asm code here" : Output : Input);
PKK> * __asm__("asm code here" : Output : Input : Clobbers);
PKK> * __asm__ goto("asm code here" : Output : Input : Clobbers : Labels);
PKK> 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).
PKK> Philipp
--
Best regards,
Tony mailto:unt...@mail.ru
_______________________________________________
Sdcc-user mailing list
Sdcc-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sdcc-user
