cr1901 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, CD/floppy disk theory of operation, and the 68k CPU are also on-topic. Channel logs: https://libera.irclog.whitequark.org/~h~yamahasynths
<fseidel>
there have actually been a few regressions since the early days, namely worse dbra loops
<tpw_rules>
i tried that site but could not get it to output opcodes, just textual assembly
<tpw_rules>
i think something might be broken in the backend
<fseidel>
ack, looks like you're right. -nodefaultlibs -nostartfiles is enough to get a binary output, but objdump fails when it tries to read it back
<tpw_rules>
i didn't even get that far
<Sarayan>
where pc points varies along the execution of the instructions, but at the *start* of the instruction it points at instruction address +2, and the words at instruction address and instruction address + 2 have already been read
<Sarayan>
pc essentially never contains the address of the currently executing instruction. I don't think there's even one time where it dos
<Sarayan>
does
<tunixman>
woah exterminating hardware companies with space lasers? did somebody just sing the song of my people?
<qu1j0t3>
:)
<tunixman>
oh wow what a ride that scrollback was.
<tunixman>
wait, is there a yamaha FM chip in modern smartphones?
<tunixman>
I mean I know there's an FM radio receiver, but an FM synth chip?
<tunixman>
anyway, 68k emulation.
<tunixman>
the PC contains the address of the instruction currently executing? is that right though? Doesn't the instruction load also increment PC?
<Sarayan>
No, the pc never contains the address of the instruction currently executing
<tunixman>
yeah, that's what I thought. the increment happens before the instruction is decoded...
<tunixman>
and there's no compensation in relative addressing for that... I remember this on the 6502 when I was a wee kiddie getting totally tripped up by that.
<tunixman>
which is basically a kinder, gentler 68k iirc...
<Sarayan>
6502 is funky in what it pushes to the stack on jsr
<Sarayan>
and yeah, on the 6502 too the pc never contains the address of the instruction currently executing
<tunixman>
oooh jsr
<tunixman>
don't forget the bcd mode bug.
<Sarayan>
remind me?
<cr1901>
Sarayan: That may be true from the actual implementation, but I'm guessing Motorola's manual found it simpler to lie and do everything in terms of "relative to the first words of the current insn"
<cr1901>
Anyways, who is right- Easy68k or me?
<cr1901>
(re: but at the *start* of the instruction it points at instruction address +2)
<tunixman>
the bcd bug I think was in an interrupt the bcd status bit wasn't properly preserved, so if the interrupt trashed it you'd wind up not in BCD mode mid stream.
<tunixman>
I think.
<tunixman>
it was a long time ago...
<qu1j0t3>
tunixman: oh boy. i know of a modern analog of that bug
<NiGHTS>
MOS Technology 6502 - Bugs and Quirks | Bugs Quirks
<tunixman>
qu1j0t3: if there were no bugs we'd have to invent them.
<qu1j0t3>
I'm doing my best
<Sarayan>
cr1901: at the start of an instruction the 68000 has start address+2 in registers au and pc, the word at start address in ird and ir, the word at start adress+2 in irc and dbin and the instruction-associated constant in ftu
<Sarayan>
gah fucking tabs
<Sarayan>
m_ird = m_ir;
<Sarayan>
m_edb = m_opcodes.read_word(m_aob);
<Sarayan>
m_icount -= 4;
<Sarayan>
m_irc = m_edb;
<Sarayan>
m_dbin = m_edb;
<Sarayan>
set_ftu_const();
<cr1901>
I only know what IRD and PC is of all those internal registers
<cr1901>
Anyways looks like Easy68k is wrong and "D6 3B 20 02" is the intended encoding of "PC-relative load of data just after the insn"
<NiGHTS>
Addressing mode PC with displacement broken? · Issue #3 · ProfKelly/EASy68K · GitHub
<tunixman>
t qu1j0t3 when our only value is the work we do visibly we create visibly impactful work
<cr1901>
"t qu1j0t3"? What's the "t" for?
<tunixman>
"tell"
<qu1j0t3>
also "terrible"
<tunixman>
trifecta
<fseidel>
RE: PC pointing at current instruction, I can think of one ISA where it does: ARM64
<fseidel>
they probably wanted to make up for 32-bit ARM doing the silly "2 instructions ahead" business that stopped making sense once branch prediction became a thing
<fseidel>
oh, I think RISC-V also has PC point at the current instruction
<cr1901>
RISCV points at the current insn
<qu1j0t3>
point long at the current instruction and the current instruction will point to you