 No.23541
Robbbert Moderator
9 days ago
|
Seems to work ok. Perhaps you can give an example? |
|---|---|
 No.23542
hap Developer
8 days ago
|
Unable to confirm either, on both 0.277 (the one you claim is the regression version) and also on current. Ball breaks the bricks. With either -nodrc or -drc. |
 No.23543
M.A.S.H. Senior Tester
8 days ago
|
Didn't test the 64bit version. Changed report to 32bit MAME version. Sorry for that!. |
|
No.23545
hap Developer
8 days ago
|
Probably a regression with drcbex86.cpp then. Or, does the bug happen with -nodrc as well? |
|
No.23549
M.A.S.H. Senior Tester
7 days ago
|
@hap The 32bit MAME version worked with mame poosho -nodrc Thx for the info! |
|
No.23563
Robbbert Moderator
3 days ago
|
I've set it to confirmed, and Vas can decide what he wants to do about it. |
 No.23564
cuavas Administrator
3 days ago
|
It’s another case of something that was always broken in the i686 recompiler back-end but wasn’t obviously getting hit by any CPU cores before. Any 64-bit rotate on UML register I1 would nuke the low 32 bits of the result. |
|
No.23565
M.A.S.H. Senior Tester
3 days ago
|
MAME 32-bit compiled and tested with “Poosho Poosho” – works. Thx hap and Vas! |
|
No.23571
cuavas Administrator
10 hours ago
|
I really shouldn’t have looked at drcbex86.cpp – there are so many cases where it doesn’t correctly clear the upper half of a register after a 32-bit load, but it also clears the upper half of “hot” registers excessively. Its be_parameter class needs to be reworked to fix this, and it needs to track additional state across instructions. Speaking of which, the way it tracks what memory values it’s got in temporary registers is horrible and needs to be completely changed, too. It’s a hot mess and almost not worth trying to fix. At least x86-64 and AArch64 are in better condition. |