On Mon, 29 Jul 2019, Segher Boessenkool wrote:
On Mon, Jul 29, 2019 at 04:34:18PM +0200, BALATON Zoltan wrote:
Note that all those are bus-specific, and a correct implementation of these words has to look at the FCode 235 (etc.) of the bus you are on, and inherited from its parent bus, etc.
I don't understand any of the above... What's FCode 235? Also OpenBIOS
FCode hex 235. The FCode generated for rl! iirc. This is pretty trivial to look up, btw.
I did try to look up but haven't succeeded. Checked forth/device/table.fs in OpenBIOS but that does not have indexes so it's not obvious what 235 means (also wasn't sure if it's hex or dec, now I at least know its h# 235 or 0x $ h or whatever convention one prefers). I've also tried searching for "fcode bytecode" to find out which did turn up some docs but not any tables about which number means what so it does not look too trivial to decode this. Maybe if you know where to look it is so you could tell us.
Now that I look at table.fs again it has these lines:
4 n['], reserved-fcode \ 22a-22d 64bit? [IF] ['], (rx@) ['], (rx!) [ELSE] 2 n['], reserved-fcode \ 22e-22f [THEN] ['], rb@ ['], rb! ['], rw@ ['], rw! ['], rl@ ['], rl!
So 235 may be rl! but it's far from obvious to get from this and only possible because there happens to be a comment near that.
only handles one PCI bus at the moment so not sure that additional complexity you mention exists in it yet. The io* words do what needs to be done to read and write mapped registers (on ppc doing eieio or similar,
Which isn't enough in all cases.
In what cases is it not enough? For PPC the low level in/out functions that the io words use are defined in openbios/include/arch/ppc/io.h (there are similar definitions for other archs but I did not really check those; it may not work with x86 where io space is different but I don't think OpenBIOS currently works on x86 or is used with anything so I did not care about that much).
otherwise same as memory read/write as all io is memory mapped on that platform)
It is not, not on PowerMac anyway, which is what you emulate? Not all PCI buses have a legacy I/O direct mapped, for example, and later machines do not even have all config space direct mapped.
OK we only emulate a few of those machines and the mac99 that I've tested is approximately a PowerMac3,1 or not even that but simpified a bit so I don't really care if theoretically there could be machines where it's not only mmio if we don't have any of those in QEMU. (It might be nice to make OpenBIOS work with real machines but currently it doesn't and that's out of scope for me.)
so I think for now this might be sufficient even if not correct at least on PPC. (Since I don't have enough knowledge to make it correct I had to hack it together so it does what I need to run the FCode I wanted to test without exception but it may not be correct.)
Sure it's a step up from not doing anything here, but you will run into trouble very soon.
If you see where we might run into trouble please explain so we don't have to debug that when it happens and we're aware of the limitations this solution has. If it's not too difficult to improve it I might even try to do that but currently I don't know what would need to be improved as my understanding is limited and so is my time to broaden my understanding so I have to rely on people telling me what they already know.
Regards, BALATON Zoltan