|
rjmccall posted:apple's arm32 abi is pretty terrible, mostly around floating-point arguments. the calling convention clearly predates the idea that arm processors might drive general-purpose computation and/or actually have a floating-point unit; it's basically an all-arguments-on-stack convention that pops the first 16 bytes into integer registers, which means e.g. an early double will get passed as two ints. also the arm bitfield layout rules are needlessly different from the standard sysv rules actually that's something that i've wondered about. was there any particular reason apple had to use the lovely arm abi rather than diverging like with arm64, or is that just one of those ideas that just never came up until years after it was too late to be practical?
|
#
?
Jul 1, 2017 05:49
|
|
|
|
| # ? Apr 28, 2024 05:49 |
|
|
that predates me, but the story i've heard is that it was just expedient: it was the only abi implemented in the version of gcc we were using for bringup. there was plenty of other compiler work to do at the time, and it was okay to put off because we didn't have binary compatibility requirements until we added the app store. we did actually change a bunch of stuff before releasing the first ios sdk, including some fundamental abi stuff; for example, earlier versions of ios actually used the fragile objc runtime and setjmp/longjmp exceptions. but there was too much other stuff in flight, and too much assembly already written, for anybody to go back and change the basic calling convention the apple arm64 abi is actually very close to arm's. the major difference is the variadic calling convention. my understanding is that arm was considering using our rule but ultimately backed off because they got tired of chasing down the bugs it was exposing. i remember a lot of grumbling within apple, too, but it's just such a superior way of doing varargs that we decided to persevere
|
|
#
?
Jul 1, 2017 08:24
|
|
|
rjmccall posted:earlier versions of ios actually used the fragile objc runtime you mean as opposed to the Foundation framework? btw why don't you publish the source code, I'm tired of using gnustep as a reference
|
|
#
?
Jul 1, 2017 09:53
|
|
|
rjmccall posted:the apple arm64 abi is actually very close to arm's. the major difference is the variadic calling convention. my understanding is that arm was considering using our rule but ultimately backed off because they got tired of chasing down the bugs it was exposing. i remember a lot of grumbling within apple, too, but it's just such a superior way of doing varargs that we decided to persevere how complex can a variadic calling convention be? and why would it be exposing bugs?
|
|
#
?
Jul 1, 2017 14:49
|
|
|
there’s a lot of old bad c code that assumes it’s still 1979 and arguments are always passed on the stack, so assumes void (*)(butts, ...) can be cast to void (*)(butts, farts) or K&R-style void (*)() and still be called. the c standard says calling a variadic function as not variadic or vice versa is undefined behavior, but most ABIs oblige and implement varargs in a way that works with the normal convention. a lot of bad code also assumes va_list is a flat array of bytes. this is why a lot of older risc-ish abis, rjmccall mentioned 32 bit ARM but also alpha, ppc, and even win64, pass arguments in registers but also reserve shadow space on the stack. that way va_start can spill all the argument registers into their shadow slots, and then va_list can “just” be a flat array. this of course wastes a ton of stack space with x86-64 amd finally said “use va_arg you idiots” and standardized the abi to only pass args in registers without reserving shadow stack space. however they still maintained compatibility between variadic and normal calling conventions, so the va_list implementation is a nightmare. read https://software.intel.com/sites/default/files/article/402129/mpx-linux64-abi.pdf#page55 to be terrified apple arm64 finally did the reasonable thing and said, hey, you can’t do this, it’s UB so the compiler will gently caress you over even if the runtime abi seems to work. so normal arguments get passed in registers and varargs get passed on the stack
|
|
#
?
Jul 1, 2017 16:07
|
|
|
that's a great explanation and i have nothing to add to it
|
|
#
?
Jul 1, 2017 17:56
|
|
|
I left GCC 5.2 compiling on my G3 iMac all night and when I checked it in the morning it had failed with a CPU subtype not supported error thanks homebrew thomebrew
|
|
#
?
Jul 1, 2017 20:05
|
|
|
hey, how about we make a c compiler that doesn't need declarations of local functions before use because it's not the 70's anymore? no, I don't care about the standard.
|
|
#
?
Jul 2, 2017 03:45
|
|
|
i think that would be pretty cool and good, especially seeing as arduino-C has done that for a decade with no issues
|
|
#
?
Jul 2, 2017 03:47
|
|
|
rjmccall posted:apple's arm32 abi is pretty terrible, mostly around floating-point arguments. the calling convention clearly predates the idea that arm processors might drive general-purpose computation and/or actually have a floating-point unit; it's basically an all-arguments-on-stack convention that pops the first 16 bytes into integer registers, which means e.g. an early double will get passed as two ints. also the arm bitfield layout rules are needlessly different from the standard sysv rules AEABI was out before we shipped the Aspen OS 2 (with the App Store) and it fixes most of the stupid things in the old ABI, including passing floating point arguments in FPU registers. iPod engineering switched to it because they were using ARM's compiler. iPhoneOS didn't because they were stuck with lovely gcc.
|
|
#
?
Jul 2, 2017 04:13
|
|
|
yeah, eabi is a lot better, as is the abi we use for the watch
|
|
#
?
Jul 2, 2017 04:28
|
|
|
The Management posted:hey, how about we make a c compiler that doesn't need declarations of local functions before use because it's not the 70's anymore? use c++ and make all of your functions templates
|
|
#
?
Jul 2, 2017 06:27
|
|
|
Plorkyeran posted:use c++ you go to hell
|
|
#
?
Jul 2, 2017 06:31
|
|
|
you guys are really smart
|
|
#
?
Jul 4, 2017 05:43
|
|
|
theodop posted:you guys are really smart 
|
|
#
?
Jul 4, 2017 05:48
|
|
|
rjmccall posted:yeah, eabi is a lot better, as is the abi we use for the watch the watch has its own abi ? (as a related matter: does the touchbar run the same OS as the watch?)
|
|
#
?
Jul 4, 2017 23:13
|
|
|
watchOS and tvOS are really wacky and different in ways that you would probably not expect
|
|
#
?
Jul 4, 2017 23:29
|
|
|
i guess "wacky" has overly negative connotations, but they definitely took advantage of the chance to make backwards-incompatible changes
|
|
#
?
Jul 4, 2017 23:30
|
|
|
Notorious b.s.d. posted:the watch has its own abi ? what do you mean when you say "the same OS"?
|
|
#
?
Jul 4, 2017 23:49
|
|
|
tvOS uses the normal arm64 abi iirc, there are just some framework level changes watchOS is very different at the abi level because as mentioned the 32-bit iOS abi really sucks
|
|
#
?
Jul 5, 2017 00:00
|
|
|
The Management posted:what do you mean when you say "the same OS"? well it didn't dawn on me until you guys brought it up that they would be anything but ios since you are using a non-ios 32 bit abi, does that mean the whole system is 32 bit? is there a 32 bit kernel shared between watchos and ... whatever runs on the touchbar embedded thing?
|
|
#
?
Jul 5, 2017 15:30
|
|
|
Notorious b.s.d. posted:well it didn't dawn on me until you guys brought it up that they would be anything but ios the definition of what is "iOS" is not exactly clean cut. it runs a Darwin OS (kernel plus system libraries), which is the same on everything from watch to phone to Mac. it has some kind of UI framework that is probably based on UIKit but who knows how they cut it down. since it doesn't run third party apps I don't see why it matters what the ABI is, they chose the best one for the architecture.
|
|
#
?
Jul 5, 2017 16:06
|
|
|
the kernel isn't the same everywhere. it's a single code base, but there's nontrivial differences in what's enabled for each platform
|
|
#
?
Jul 5, 2017 19:26
|
|
|
it's not literally the same build, no, but we manage to say that various linux distributions are built on the same kernel despite each configuring it differently
|
|
#
?
Jul 5, 2017 19:46
|
|
|
i got tricked by a compiler i left a status thing uninitialized, it determined that the only value assigned was ERROR, elided the entire function and just kicked that back that all makes sense, but why wouldn't volatile writes prevent the total collapse? shouldn't those get preserved even if the rest of the code drops away?
|
|
#
?
Jul 5, 2017 20:25
|
|
|
JawnV6 posted:i got tricked by a compiler it probably decided that something you were doing was undefined behavior and therefore that such-and-such path could never be taken
|
|
#
?
Jul 5, 2017 20:41
|
|
|
that'll teach you to program in C 
|
|
#
?
Jul 6, 2017 03:27
|
|
|
rjmccall posted:something you were doing was undefined behavior 
|
|
#
?
Jul 7, 2017 17:49
|
|
|
I.e., you were writing a non trivial program
|
|
#
?
Jul 7, 2017 17:51
|
|
|
|
|
#
?
Jul 7, 2017 19:46
|
|
|
the volatile write was to a global variable, right, and not to something local like a pointer you declared locally within the function?
|
|
#
?
Jul 7, 2017 20:03
|
|
|
The Management posted:I.e., you were writing a program
|
|
#
?
Jul 7, 2017 23:10
|
|
|
avoiding ub is easy, just follow these 204 simple rules https://blog.regehr.org/archives/1520
|
|
#
?
Jul 8, 2017 02:48
|
|
|
i wanna compile a butt irl, but how?
|
|
#
?
Jul 8, 2017 02:55
|
|
|
Powaqoatse posted:i wanna compile a butt irl, but how? txt me
|
|
#
?
Jul 8, 2017 04:13
|
|
|
TOPS-420 posted:avoiding ub is easy, just follow these 204 simple rules is there a reason they don't get rid of all the ub for trivial things like syntax errors? how did "An unmatched ‘ or ” character is encountered on a logical source line during tokenization (6.4)" survive into this century?
|
|
#
?
Jul 8, 2017 04:40
|
|
|
A Pinball Wizard posted:txt me no u 
|
|
#
?
Jul 8, 2017 04:58
|
|
|
Dylan16807 posted:is there a reason they don't get rid of all the ub for trivial things like syntax errors? how did "An unmatched ‘ or ” character is encountered on a logical source line during tokenization (6.4)" survive into this century? practically speaking, they haven't; there are no significant compilers that will fail to diagnose that
|
|
#
?
Jul 8, 2017 05:42
|
|
|
Powaqoatse posted:i wanna compile a butt irl, but how? first you need a butt compiler compiler
|
|
#
?
Jul 8, 2017 06:20
|
|
|
|
| # ? Apr 28, 2024 05:49 |
|
|
Dylan16807 posted:is there a reason they don't get rid of all the ub for trivial things like syntax errors? how did "An unmatched ‘ or ” character is encountered on a logical source line during tokenization (6.4)" survive into this century? Why can there be undefined behaviour at parsing time?
|
|
#
?
Jul 8, 2017 11:44
|
|