ChanServ changed the topic of ##yamahasynths to: Channel dedicated to questions and discussion of Yamaha FM Synthesizer internals and corresponding REing. Discussion of synthesis methods similar to the Yamaha line of chips, Sound Blasters + clones, PCM chips like RF5C68, and CD theory of operation are also on-topic. Channel logs: https://freenode.irclog.whitequark.org/~h~yamahasynths
<cr1901_modern>
ZirconiumX: Oh, so they saved it after all
<cr1901_modern>
There was a $1500 bounty to convert status register handling from the old method to the new one
<ZirconiumX>
They crowdfunded some dev for it, yeah
<cr1901_modern>
if I didn't get sick (and a few other factors were favorable), I would've considered doing it myself... and it would've been painful as hell
andlabs has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<Lord_Nightmare>
from the comments there it could still use some improvement and trimming of many of the special cases some of which are irrelevant/possibly detrimental
<Lord_Nightmare>
but it works
<Lord_Nightmare>
and its probably light years better than whatever POS compiler dec used for the dectalk 1.8 and 2.0 firmware, most of which was written in C
<Lord_Nightmare>
with a few pieces in asm
<Lord_Nightmare>
c compilers for 68k in 1983 sucked ass
<Lord_Nightmare>
from what i gather the first actually half decent compilers were late 80s
<Lord_Nightmare>
the nice thing about the godawful code produced by the 1983 compiler is there's almost no optimization to speak of, so its pretty obvious what a lot of code was supposed to do
<Lord_Nightmare>
there's also bugs. lots of them, in the libc that was used
<Lord_Nightmare>
string handling fails catastrophically in the length-of-zero case for instance
<Lord_Nightmare>
doesn't match posix
<Lord_Nightmare>
also the compiler doesn't purely follow the "conventional" way of doing fastcalls etc which most c compilers ended up standardizing on later, i guess
andlabs has joined ##yamahasynths
<ej5>
c compilers were the wild west back then.
<ej5>
Lord_Nightmare, i heard a talk by Tom Duff about how he came up with Duff's Device. it occurred to him after reading the source code to the C compiler.
<ej5>
basically there was a giant switch statement on the current statement, and he noticed that the code implementing "switch" and "case" had nothing in common with the code implementing the "while" loop.
andlabs has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
andlabs has joined ##yamahasynths
<cr1901_modern>
does Duff's Device predate the 1989 spec?
<cr1901_modern>
Anyways, hope someone steps up to save AVR and VAX
<cr1901_modern>
Though AVR is probably safe since it has an LLVM backend upstream
andlabs has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
andlabs has joined ##yamahasynths
andlabs has quit [Client Quit]
andlabs has joined ##yamahasynths
andlabs has quit [Ping timeout: 245 seconds]
andlabs has joined ##yamahasynths
<__sen>
cr1901_modern: what's this about VAX? I looked through scrollback but can't figure out what you're referring to
<cr1901_modern>
__sen: gcc for VAX uses an old model in the RTX/RTL IR for condition codes. As of gcc 10, this old model is deprecated, and the plan is to phase out any archs that use the old model by gcc 11
<cr1901_modern>
68k got a crowdfund campaign which resulted in a gcc contributor doing the conversion themselves.
<cr1901_modern>
I am wondering if there are efforts to do the same for VAX (and jury's still out on that one)
<cr1901_modern>
NetBSD mailing list still has a decent amount of VAX activity, and talks about gcc refactor