[tools] Update binutils-ia16/gcc-ia16 to latest revision

[asiekierka]

As neither project has received updates in some time, it might be a good idea to sync up with the latest revision.

There are some non-ELKS-specific bug fixes, as well as a minor improvement to instruction cost analysis for the code generation back end I contributed.

[ghaerr]

Hello @asiekierka,

I'd like to put this update on hold, commit date to be determined, probably closer towards the end of the 0.9 dev cycle. Unfortunately, updating the massive GCC compiler isn't as automatic as we'd like on all our developer's systems, and there remain several open issues getting through all the hoops, particularly on macOS, I don't recall all of it.

Since the ia16-elf-gcc compiler has had very few updates that actually matter to ELKS, I have taken the approach of not updating, rather than forcing our developers to stop what they're doing and update the compiler. (I'm one of those people that doesn't update his phone right aways either, for what that's worth). Right now is a particularly bad time for an update as there seems to be an increase in interest for developing on ELKS recently.

I wasn't aware you've made a contribution that might help code generation on ELKS (which optimization or tuning settings are affected?), although I remain particularly concerned with code generation changes since our kernel heavily depends on ia16-elf-gcc, and there are some outstanding bug reports of bad code being generated (IIRC, they may in fact be from you on codeberg.org)?

Lets keep this open for more discussion, thank you.

[asiekierka]

Unfortunately, updating the massive GCC compiler isn't as automatic as we'd like on all our developer's systems, and there remain several open issues getting through all the hoops, particularly on macOS, I don't recall all of it.

There was a patch to fix (or at least improve) the situation of building gcc-ia16 on macOS made since the last toolchain version used. But I do agree that the changes are far too inconsequential to justify this kind of effort.

(which optimization or tuning settings are affected?)

Anything that is not -O0; the patch allows more accurate estimation of the cost of segment and accumulator MOVs, in particular. The details are here. However, the resulting difference is fairly subtle and ultimately inconsequential.

and there are some outstanding bug reports of bad code being generated (IIRC, they may in fact be from you on codeberg.org)?

Most issues regarding the generation of bad code on gcc-ia16 concern edge cases involving far pointers; we've also had an user report an issue around C bitfields, but I'm not sure if that too wasn't connected to far pointers. Note that one of the patches should actually improve this by disabling a known-to-crash optimization when far pointers are involved.

(One day, I want to try working on a port of LLVM to the 8086, but that day won't come for a long time...)