Porting GCC

[Basile Starynkevitch]

On Sat, 2025-09-06 at 09:35 +0100, Jonathan Wakely via Gcc-help wrote:
> On Sat, 6 Sept 2025, 06:34 Basile Starynkevitch, <basile@starynkevitch.net>
> wrote:
> 
> > .
> > 
> > 
> > If HPE Nonstop has some specific to HPE coding rules, tell us more about
> > them, then consider first writing your GCC plugin
> > (it has to be open source and could be inspired from
> > https://arxiv.org/abs/1109.0779 and obsolete code on
> > https://github.com/bstarynk/bismon that you will need to improve and port)
> > 
> 
> Basile,
> 
> Please stop telling people to write their own GCC plugins. 
> 



>  A plugin is not relevant to porting to a new OS.



it definitely is if the OS has an API not supported by current GCC 

And once you have an open source plugin, proposing to merge it inside GCC is simpler (both technically and politically).

On the other hand most OSes have today some POSIX compatibility. For those OSes running on Intel processors the porting effort should be very small

But if you write a brand new OS (and kernel with its own API) and want to support GCC on that new OS (which is supposed to be non POSIX) you need documentation of that OS.

For example take GNU hurd or https://en.wikipedia.org/wiki/L4_microkernel_family

(I don't know if GCC is ported to L4; I heard it have been)

At last, many libraries define an API and it makes sense to have some code to check compliance with that API.

(it could be outside of GCC, e.g. frama-c.com based)



-- 
Basile STARYNKEVITCH                            <basile@starynkevitch.net>
8 rue de la Faïencerie                       http://starynkevitch.net/Basile/  
92340 Bourg-la-Reine                         https://github.com/bstarynk
France                                https://github.com/RefPerSys/RefPerSys