[Self-interest] C preprocessor for asm

[Tobias Pape]

Hi uwe

Some ten years ago I ran into similar problems,
even though clang was "younger" then and GCC a bit different.

I wrote about that here:
	https://blog.selflanguage.org/2012/07/02/assembler-woes/


> On 18. Dec 2022, at 01:30, Valery Ushakov <uwe at stderr.spb.ru> wrote:
> 
> Asm sources in Self currently use assembler's macro facilities that
> differ between clang and gas.  Recent versions of clang asm is gas
> compatible, but then as far as I understand apple's clang is special.
> llvm's asm behaves differently if "IsDarwin" and the current llvm
> macro code in Self is effectively apple-only.

yeah, because I developed on my apple machine with Xcode tools and 
hence an "early" clang.

> 
> I'm working on a NetBSD port and NetBSD supports both gcc and clang as
> system compilers.  I will porbably look at the FreeBSD port too and
> FreeBSD is now clang only, afaik.  This makes it a bit painful to work
> with the current asm sources.
> 
> Would there be any objections to switching Self i386 asm sources to
> use the C pre-processor?  NetBSD has been doing that for ages (for a
> large zoo of CPUs) and it's quite ok.
> 
> Some examples
> 
> https://github.com/NetBSD/src/blob/trunk/sys/arch/i386/include/asm.h
> https://github.com/NetBSD/src/blob/trunk/lib/libc/arch/i386/SYS.h
> 
> just to give a general idea of what it looks like.  So, e.g.
> 
>   start_exported_function currentFrame
> 
> will just become
> 
> 
>   start_exported_function(currentFrame)
> 
> Or
> 
>   MACRO(ret_prim_error, error_code)
>       ...
> 
>   ret_bad_type: ret_prim_error badTypeOffset
> 
> 
> will be
> 
>   #define ret_prim_error(error_code) \
> 	... ; \
>       ...
> 
>   ret_bad_type: ret_prim_error(badTypeOffset)

All .S files (capital S) are passed through CPP anyway

I don't know whether there's a huge loss wenn switching from assembler macros to preprocessor...

So why not?

	-Tobias