@cmuratori @natbro Currently all x64 targets differ because their compilers do different things with "undefined"!
-
-
Replying to @cmuratori
@cmuratori@natbro So saying that the CPU is in charge makes porting _more_ likely to work than it does now.1 reply 0 retweets 0 likes -
Replying to @cmuratori
@cmuratori@natbro It takes compilers out of the equation, and leaves only CPUs, instead of having _both_ like we do now.1 reply 0 retweets 2 likes -
Replying to @cmuratori
@cmuratori hear you & agree, but i mean taking 32- or 64-bit code to other CPUs - i would have /many/ more loc to examine.1 reply 0 retweets 0 likes -
Replying to @natbro
@cmuratori i mean maybe it would *force* me to look at all the loc like i should anyway because of inconsitent compilers? :)1 reply 0 retweets 0 likes -
Replying to @cmuratori
@cmuratori@natbro Like since the behavior was _undefined_ before, you certainly couldn't have counted on what it would do on other CPUs!1 reply 0 retweets 0 likes -
Replying to @cmuratori
@cmuratori yeah, but fwtfiw some compilers - gcc/clang, even msvc multi-arch - you can basically count on consistency across backends.1 reply 0 retweets 0 likes -
Replying to @natbro
@cmuratori so moving code between archs, you had a /wee/ less to check. but let's agree: what a goddam shitshow, we're splitting hairs :)1 reply 0 retweets 0 likes
@cmuratori @natbro There wasn't less to check - in fact there's more to check, because it _will_ break code that _would've_ worked?
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.