- On SysV, the ABI document is not as formal as it should be, so the conventions for anything that isn't a simple scalar type is emergent behavior that compilers have sorta agreed on, mostly.
-
-
Even for scalar types, there's no clearly specified rules for how to add new types. So, e.g. I've been pushing to define an ABI for _Float16. Right now, many compilers do ~something~ with it. That will either have to change, or be inconsistent once it's defined.
3 replies 0 retweets 4 likes -
If you want to claim a consistent and stable ABI, you need a completely unambiguous procedure to map *any type the language may support, even one you don't know about yet* onto a calling convention.
3 replies 0 retweets 11 likes -
Hm. We don't have that for Swift either, but we're skating around it by only having one implementation, I guess?
1 reply 0 retweets 0 likes -
We try: https://github.com/apple/swift/blob/master/docs/CallingConvention.rst#physical-conventions …
1 reply 0 retweets 1 like -
I guess we're screwed if someone comes up with a "legal type" that isn't an int, float, or vector type though
2 replies 0 retweets 0 likes -
I guess I was thinking about what Float16 will do to Swift, and the answer is "whatever it does in C". But if Swift were to get it before C…
1 reply 0 retweets 0 likes -
Widen to float32 and pass it like a 32
2 replies 0 retweets 0 likes -
-
Replying to @stephentyrone @UINT_MIN and
Ok ok widen to float64 and pass it like a 64. Soft float 64 of course.
1 reply 0 retweets 2 likes
No, clearly the right answer is to widen to 80 bits and pass them in x87 FP registers
-
-
Replying to @pcwalton @jfbastien and
All arguments shall be passed by leaking them from micro-architectural side-channels
0 replies 0 retweets 4 likesThanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.