|
eschaton posted:I’ve been writing some plain ANSI C89 (with sprinkles) for fun and it’s honestly really fun and refreshing Yeah it's good. Even the ancient compilers I'm working with support an extension for // comments
|
#
?
Oct 4, 2023 15:11
|
|
|
|
| # ? May 26, 2024 21:35 |
|
|
redleader posted:the compiler's understanding of undefined behaviour has gotten more complex, and now the code doesn't work that’s why if you live in hell they specify which ancient compiler and set of flags you’re required to use
|
|
#
?
Oct 4, 2023 15:20
|
|
|
Bloody posted:that’s why if you live in hell they specify which ancient compiler and set of flags you’re required to use Nice of them to specify them rather than make your read the foreign language manuals
|
|
#
?
Oct 4, 2023 15:26
|
|
|
the one non-O flag which may make sense to add to things you're building for personal use is -march=native, which makes it target your cpu rather than very old ones and sometimes meaningfully improves performance
|
|
#
?
Oct 4, 2023 16:50
|
|
|
yeah linux is very held back by its minimum cpu targets, especially on i386. some of that is even baked into the abi, like fp values being returned in x87 registers. turns out being able to use the last thirty years of isa improvements is pretty good
|
|
#
?
Oct 4, 2023 16:54
|
|
|
|
|
#
?
Oct 4, 2023 17:43
|
|
|
i think you'll find the possibilities are rather limited
|
|
#
?
Oct 4, 2023 18:03
|
|
|
Internet Janitor posted:i think you'll find the possibilities are rather limited yeah, limited only by your imagination
|
|
#
?
Oct 4, 2023 18:04
|
|
|
rjmccall posted:yeah linux is very held back by its minimum cpu targets, especially on i386. some of that is even baked into the abi, like fp values being returned in x87 registers. turns out being able to use the last thirty years of isa improvements is pretty good so what you’re saying is, the gentooers are right
|
|
#
?
Oct 4, 2023 18:09
|
|
|
Kazinsal posted:yeah, limited only by your imagination
|
|
#
?
Oct 4, 2023 18:15
|
|
|
if x86 mov is turing-complete why not nop
|
|
#
?
Oct 4, 2023 19:26
|
|
|
I'm not ready to go all the way to no code but I'm willing to hop onboard with the slow code movement
|
|
#
?
Oct 4, 2023 19:30
|
|
|
mystes posted:I'm not ready to go all the way to no code but I'm willing to hop onboard with the slow code movement baby steps
|
|
#
?
Oct 4, 2023 19:31
|
|
|
mystes posted:I'm not ready to go all the way to no code but I'm willing to hop onboard with the slow code movement ah, a python programmer
|
|
#
?
Oct 6, 2023 05:05
|
|
|
rjmccall posted:yeah linux is very held back by its minimum cpu targets, especially on i386. some of that is even baked into the abi, like fp values being returned in x87 registers. turns out being able to use the last thirty years of isa improvements is pretty good Good thing things are mostly x86-64 now where at least you get SSE2... (is i386 even much of a thing these days other than seriously legacy stuff? Especially with Linux? I can't imagine it being my first choice for e.g. embedded anything these days, we seem to mostly moved on from using DOS for that sort of thing) feedmegin fucked around with this message at 14:45 on Oct 6, 2023 |
|
#
?
Oct 6, 2023 14:36
|
|
|
having SSE2 available for passing vector values is nice but floating point ones are just passed in memory for AMD64 now, right? I don’t know how L1$ operations compare to x87 registers in terms of performance these days, tbh
|
|
#
?
Oct 6, 2023 14:52
|
|
|
Subjunctive posted:having SSE2 available for passing vector values is nice but floating point ones are just passed in memory for AMD64 now, right? I don’t know how L1$ operations compare to x87 registers in terms of performance these days, tbh there are three major x86_64 calling conventions: the windows default cc, the unix default cc, and windows __vectorcall. all three pass scalar fp arguments and return values in xmm registers the default windows convention passes vector arguments indirectly, and both windows conventions needlessly exhaust registers when you declare a parameter of a different type. i do not know why microsoft is so bad at designing calling conventions
|
|
#
?
Oct 6, 2023 17:49
|
|
|
Subjunctive posted:having SSE2 available for passing vector values is nice but floating point ones are just passed in memory for AMD64 now, right? I don’t know how L1$ operations compare to x87 registers in terms of performance these days, tbh A vector of length 1 is still a vector.
|
|
#
?
Oct 6, 2023 21:06
|
|
|
yeah, abis don’t do it that way
|
|
#
?
Oct 6, 2023 21:38
|
|
|
feedmegin posted:A vector of length 1 is still a vector. sorry but I flunked pre-calculus
|
|
#
?
Oct 6, 2023 22:18
|
|
|
rjmccall posted:the default windows convention passes vector arguments indirectly, and both windows conventions needlessly exhaust registers when you declare a parameter of a different type. i do not know why microsoft is so bad at designing calling conventions the main reason early UNIX 68K compilers wound up burning address and data registers was because they were adapted from PDP-11 compilers and the -11 only has general registers r0-7, not distinct a0-7 and d0-7, and it’s easier to just keep a bit per register as to whether to use an a or d in the generated assembly… who the gently caress knows what MS’s excuse for x86-64 codegen burning registers is
|
|
#
?
Oct 7, 2023 12:20
|
|
|
rjmccall posted:yeah, abis don’t do it that way you know full well ABIs do all sorts of crazy poo poo OS-9/68K’s syscall ABI uses the TRAP instruction, but instead of putting a selector code in D0 like most 68K OSes, or using illegal instruction dispatch like Apple and Atari, you put the selector directly in the instruction stream immediately after the TRAP instruction the dispatcher then fetches it from memory instead of having it already in a register, and has to fix up the program counter prior to exit from the kernel as well disassemblers have to know about this to avoid bogus disassembly the really funny thing is, this is basically what SOS on Apple III and ProDOS on Apple II does, specifically because of the super-small stack on 6502 (one 256-byte page, not relocatable, no separate supervisor or interrupt stack) neither 6809 nor 68000 needs that because they both have separate, relocatable supervisor and user stacks eschaton fucked around with this message at 12:29 on Oct 7, 2023 |
|
#
?
Oct 7, 2023 12:23
|
|
|
my knowledge is hopelessly out of date, but I recall the x87 registers having a huge penalty? perhaps it's just when you try to switch back and forth between that and the XMM/YMM stuff, but I really thought that nuked the pipeline at some point
|
|
#
?
Oct 18, 2023 01:04
|
|
|
the x87 registers are a pain in the rear end because the x87 is actually a stack machine, a lot of the operations depend on that. the biggest penalty they have is if you're using MMX instructions because they use the same physical registers codegen for them is just absolutely atrocious too because of the additional instructions needed to deal with the fact that they're 80 bits wide
|
|
#
?
Oct 18, 2023 01:13
|
|
|
more accuracy is better, right?
|
|
#
?
Oct 18, 2023 01:46
|
|
|
all the mmx instructions immediately invalidate the entire x87 stack in a way that will cause any subsequent x87 instruction to trap. to use x87 again you have to clear the mmx state with the emms instruction. emms is pretty fast on amd but, for some reason, on intel cores it has always varied between “weirdly expensive” and “insanely expensive”. for example, agner fog says that on broadwell emms has 31 cycle latency. i assume amd is renaming fp/mmx state and intel just does it modally and has to stall. in any case it was a huge self-own that pretty much killed mmx
rjmccall fucked around with this message at 02:02 on Oct 18, 2023 |
|
#
?
Oct 18, 2023 02:00
|
|
|
once again the Motorola 68000 series demonstrates its supremacy among 80s CISC architectures imagine what an equivalent amount of work as what Intel put into x86 could have achieved
|
|
#
?
Oct 18, 2023 04:31
|
|
|
eschaton posted:once again the Motorola 68000 series demonstrates its supremacy among 80s CISC architectures I am, all day, every day, continuously pouring one out for the i432
|
|
#
?
Oct 18, 2023 21:00
|
|
|
i guess the x87 stack is an 80’s mistake. mmx re-using those registers is a completely separate 90’s mistake. emms being slow as gently caress is an 00’s and 10’s mistake. intel is a pretty bad steward
|
|
#
?
Oct 18, 2023 21:58
|
|
|
More like unintel
|
|
#
?
Oct 18, 2023 22:01
|
|
|
i always wonder what we'll look back on in 20 years and say "what the gently caress were we thinking" about
|
|
#
?
Oct 18, 2023 22:01
|
|
|
rotor posted:i always wonder what we'll look back on in 20 years and say "what the gently caress were we thinking" about legacy x86 boot paths. CSM was supposed to be phased out by 2020, but every new board still has it, sometimes enabled by default. in 2040 you will likely still be able to boot a PC into a simulation of a 5150 also probably IPv6, which is now 25 years old and, despite being supported by pretty much every network stack out there, has minimal adoption due to the complexity inherent in making an IPv6 switchover for hundreds of billions of devices happen
|
|
#
?
Oct 18, 2023 22:09
|
|
|
the problem with ipv6 is that they tried to change too much at once. if they’d just made ipv4 with longer addresses, we’d have been using it exclusively for years now
|
|
#
?
Oct 18, 2023 22:14
|
|
|
Soricidus posted:the problem with ipv6 is that they tried to change too much at once. if they’d just made ipv4 with longer addresses, we’d have been using it exclusively for years now
|
|
#
?
Oct 18, 2023 22:15
|
|
|
i actually don't have any problems with ipv6 except the longer addresses
|
|
#
?
Oct 18, 2023 22:17
|
|
|
Soricidus posted:the problem with ipv6 is that they tried to change too much at once. if they’d just made ipv4 with longer addresses, we’d have been using it exclusively for years now "bolt another two octets on" would have worked just fine instead they looked at the IPX/SPX addressing scheme and went "we can make this even more hosed up!" mystes posted:wouldn't that still have broken all existing hardware which seemed like the main issue? it would have made a 6-to-4 implementation waaaay easier at the very least, but we'd still have adoption issues due to the need to at some point say "on this day, IPv4 stops working", which, lol
|
|
#
?
Oct 18, 2023 22:18
|
|
|
Kazinsal posted:"bolt another two octets on" would have worked just fine i feel like just doubling it would be better. six octets sounds bad. eight octets sounds right.
|
|
#
?
Oct 18, 2023 22:19
|
|
|
also class E addresses never got unreserved so we're just wasting a quarter of a billion IPv4 addresses because people were concerned circa 1998 that their vintage Cisco Gateway Server wouldn't know what to do with a class E address
|
|
#
?
Oct 18, 2023 22:20
|
|
|
Kazinsal posted:"bolt another two octets on" would have worked just fine completely agreed apart from looking ugly as gently caress, just parsing ipv6 address formats is moderately complex, and that complexity (and its attendant bugs) is reflected an untold number of times across libraries and applications utterly unnecessary yak-shaving in the standard has cursed everything it touches
|
|
#
?
Oct 18, 2023 22:23
|
|
|
|
| # ? May 26, 2024 21:35 |
|
|
so like what happened to ipv5? are we just not gonna talk about that at all?
|
|
#
?
Oct 18, 2023 22:27
|
|