[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160929170801.GC22343@voyager>
Date: Thu, 29 Sep 2016 19:08:01 +0200
From: Markus Wichmann <nullplan@....net>
To: musl@...ts.openwall.com
Subject: Re: Model specific optimizations?
On Thu, Sep 29, 2016 at 11:23:54AM -0400, Rich Felker wrote:
> What kind of version-checking? Not all systems even give you a way to
> version-check.
>
To the extent that they don't, they also don't give you a way to check
for features (again, except for executing the instructions and seeing if
you get SIGILL). PowerPC (sorry, but that's where I spent a lot of time
on recently) for instance only has the PVR (Processor Version Register).
No software I could find online uses another way to detect the features
of the CPU.
And for systems to not give you a way of detecting system version at
runtime and then define optional parts of the ISA would be very dickish,
in my opinion. That basically guarentees optional functions won't be
used at all.
> This code contains data races. In order to be safe under musl's memory
> model, sqrtfn would have to be volatile and should probably be written
> via a_cas_p. It also then has to have type void* and be cast to/from
> function pointer type. See clock_gettime.c.
>
Well, yes, I was just throwing shit at a wall to see what sticks. We
could also move the function pointer dispatch into a pthread_once block
or something. I don't know if any caches need to be cleared then or not.
But yes, there are better examples.
> For some archs, gas produces an error or tags the .o file as needing a
> certain ISA level if you use an instruction that's not present in the
> baseline ISA. I'm not sure if this is an issue here or not.
>
As I said, fsqrt is defined in the baseline ISA, just marked as
optional. So any PowerPC implementation is free to include it or not.
There are a lot of optional features, and if the gas people made a
different subarch for each combination of them, they'd be here all day.
Not just instructions, too. Sometimes the optional thing is a register,
and sometimes just bits in a register.
> I think it's the #define sqrt soft_sqrt that's a hack. The inclusion
> itself is okay and would be the right way to do this for sure if it
> were just a compile-time check and not a runtime one.
>
I meant the define. While it is hacky, it does mean no code duplication
and only one externally facing symbol regarding sqrt(), which is the one
defined by the standard. Although I am abusing the little known rule
about C that if a function is declared as static in its prototype, and
the function definition doesn't have an explicit storage class
specifier, then the function will be static. Most style guides (rightly)
say to have the storage class specifier in the prototype and the
definition be the same, because otherwise this gets confusing fast.
I guess it goes to show that you should know your language even in the
parts you barely ever use (because forbidden), because they might come
in handy at some point.
> Rich
Ciao,
Markus
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
