ICE when building libgcc with -mno-callee-assume-ss-data-segment

[asiekierka]

$ make clean-target-libgcc
# ...
$ make all-target-libgcc CFLAGS_FOR_TARGET="-mno-callee-assume-ss-data-segment"
# ...
../../../gcc-ia16/libgcc/libgcc2.c: In function ‘__popcounthi2’:
../../../gcc-ia16/libgcc/libgcc2.c:858:1: internal compiler error: in elimination_costs_in_insn, at reload1.c:3624
 }
 ^

I'm starting to feel like it might be better to just add support for the Compact memory model... I'm dealing with a DS != SS platform, but -mno-callee-assume-ss-data-segment causes a lot of caveats (for example, va_list is currently expected to live in DS).

[tkchia]

Hello @asiekierka,

Yes, unfortunately support for %ss ≠ .data code is still extremely hacky and involves some not-quite-reliable deep black magic. (GCC was never quite designed in the first place to work with non-flat address spaces. Plus, the libgcc library was definitely not written with a %ss ≠ .data environment in mind.)

I am not so sure you really need to recompile an entire runtime library to work with %ss ≠ .data though.

Depending on what you want to do, you might be able to get by, with marking the relevant routines (e.g. event handlers) in your code as __attribute__ ((no_assume_ss_data)) or even __attribute__((interrupt)), while leaving the rest of your program working with %ss = .data.

---

(That said, a compiler crash is always a bug. I see that gcc-ia16 is having trouble with this RTL pattern at reload1.c line 3624:

(insn 25 24 2 2 (use (reg:PHI 24)) -1
     (nil))
(insn 27 26 9 2 (set (subreg:QI (reg:HI 38) 0)
        (mem/u/j:QI (plus:HI (plus:HI (zero_extend:HI (subreg:QI (reg:HI 38) 0))
                    (reg/f:HI 35))
                (unspec:HI [
                        (reg:PHI 24)
                    ] 1)) [0 __popcount_tab S1 A8])) ../../../../gcc-ia16/libgcc/libgcc2.c:854 -1
     (nil))

Let me see what I can find out about this crash.)

Thank you!

[asiekierka]

I'm developing a toolchain for the WonderSwan handheld with two targets:

• the first one is bare metal, and in this situation I can and do of course set DS = SS; DS is in internal console RAM, and on-cartridge ROM/SRAM reads are expected to be handled with far pointers for the time being,
• the second one is for the "WonderWitch" official personal development kit released in 2000. In this environment, DS is expected to be 0x1000 (on-cartridge SRAM), while SS is expected to be 0x0000 (internal console RAM).

It may be possible that, in the second case, I could pay a performance penalty (16-bit -> 8-bit bus) and allocate stack space in the data segment instead. However, (a) this could prevent using the toolchain to easily recompile more complex existing WonderWitch software, (b) I am not yet sure how this interacts with the abstraction layer ("FreyaOS") provided by the device. The development kit's assumption of DS != SS has caused problems even in the early 00s, after all.

EDIT: I've done some more debugging. The reason for this is because the SRAM is banked. "BIOS/OS" code uses a different bank from user code. As such, if one enters a FreyaBIOS call with SS = 0x1000, the stack can be trashed mid-interrupt, leading to undefined behavior. This might be workaroundable by changing SS/SP before an interrupt call to point to internal console RAM, then changing it back after an interrupt call. However, there's still the issue of console-emitted interrupts, and I wouldn't really want to wrap every single IVT entry on top of an abstraction layer. So that won't be great either.

I am aware that -mno-callee-assume-ss-data-segment is a hack, but I've noticed you say in past issues that a compiler crash is always a bug, so I wanted to report it from my observations nonetheless - especially as the reproduction was so easy.

[tkchia]

Hello @asiekierka,

I found the cause of the crash. The insn pattern that confused the compiler was for an xlat instruction: the ia16.md knew about an al := [bx + al] pattern (so to speak) where there was no explicit segment override, but did not know about an al := seg:[bx + al] pattern with an explicit segment override term (the (unspec: ...) portion). So I have now fixed this by adding the relevant insn pattern to ia16.md.

I have also added a test case for this to the regression test suite.

Thank you!

[asiekierka]

Thank you very much!

[ecm-pushbx]

Hi @tkchia, do you know that xlatb may not support segment overrides on some pre-386 machines? I documented this in https://hg.pushbx.org/ecm/insref/rev/9360e3b5ca1c

[tkchia]

Hello @ecm-pushbx,

Hi @tkchia, do you know that xlatb may not support segment overrides on some pre-386 machines? I documented this in https://hg.pushbx.org/ecm/insref/rev/9360e3b5ca1c

Argh! I admit that I have not heard of such a "bug" before. Also, I just looked up Harald Feldmann's 86bugs.lst (part of RBIL), and did not find any mention of this. This is not very nice, if indeed it is true.

Edit: well, yes, according to benrg on the Stack Overflow link you mentioned (https://retrocomputing.stackexchange.com/questions/20031/undocumented-instructions-in-x86-cpu-prior-to-80386), MAME's NEC CPU emulators "all don't support a segment override for XLAT (the prefix is allowed but ignored)". But after reading the actual code that he refers to (https://github.com/mamedev/mame/blob/master/src/devices/cpu/v30mz/v30mz.cpp#L3013), I am actually not so sure about that. The implementation for the 0xd7 (xlat) opcode calls a default_base(.) function... which seems to implement a segment override?

Thank you!

[ecm-pushbx]

The implementation for the 0xd7 (xlat) opcode calls a default_base(.) function... which seems to implement a segment override?

Thank you!

You're right, good catch.

[tkchia]

Hello @ecm-pushbx,

I came across this account from Chuck(G) from vcfed.org, who apparently did some tests with a real NEC V20: https://forum.vcfed.org/index.php?threads/the-d6-instruction-on-the-nec-v-series-v20-v30-chips.29471/ . I guess we can safely say that, yes, xlat did indeed support segment overrides even on that CPU. 🙂

Bottom line is that the D6 takes the low order byte in AL and uses it to fetch one byte from memory at that address into AL. Flags are not affected. So if AL=1, the contents of location 0001 will appear in AL. AH has no part in this and is not modified. Fetches are performed relative to DS, but segment overrides will work. [...]

You beat me to the punch! The D6 is in fact nothing more than an xlat [bx]. Just incomplete instruction decoding in the V-series CPU. D6 == D7.

Thank you!

[asiekierka]

But after reading the actual code that he refers to (https://github.com/mamedev/mame/blob/master/src/devices/cpu/v30mz/v30mz.cpp#L3013), I am actually not so sure about that. The implementation for the 0xd7 (xlat) opcode calls a default_base(.) function... which seems to implement a segment override?

This was changed in MAME in December 2020, which might explain it.

[ecm-pushbx]

@asiekierka Can you link the change you're referring to?

@tkchia I knew that either the V20 or the V30 worked with segment overrides because Robert tested my LZMA-lzip depacker on one once, and at the time it depended on cs xlatb and would crash if the override got ignored. However, this does not rule out that some other machines might lack the support.

[tkchia]

Hello @ecm-pushbx,

@asiekierka Can you link the change you're referring to?

I was able to find a Git mega-commit for the particular line, via its Git blame:

The mega-commit apparently came from a pull request (mamedev/mame#7428) which comprised lots of smaller commits.

Thank you!

[tkchia]

Hello @asiekierka,

It may be possible that, in the second case, I could pay a performance penalty (16-bit -> 8-bit bus) and allocate stack space in the data segment instead. However, (a) this could prevent using the toolchain to easily recompile more complex existing WonderWitch software, (b) I am not yet sure how this interacts with the abstraction layer ("FreyaOS") provided by the device. The development kit's assumption of DS != SS has caused problems even in the early 00s, after all.

Weird. In that case, how on earth did the official SDK tell apart addresses which might come from either the fast RAM (starting at 0:0) or the slow SRAM (starting at 0x1000:0) or even ROM areas? I would imagine that, for a routine like

void foo(const char *p)
{
  ...
}

a caller could jolly well pass either an address of a stack variable, or an address of a compile-time string, in p:

void bar(int x)
{
  auto char a[] = "qux";
  static char b[] = "quux";
  static const char c[] = "quuux";
  a[1] += x;
  foo(a);
  b[2] += x;
  foo(b);
  foo(c);
  ...
}

Thank you!

[ecm-pushbx]

Hello @ecm-pushbx,

@asiekierka Can you link the change you're referring to?

I was able to find a Git mega-commit for the particular line, via its Git blame:

The mega-commit apparently came from a pull request (mamedev/mame#7428) which comprised lots of smaller commits.

Thank you!

That PR changed here https://github.com/mamedev/mame/pull/7428/files#diff-850b68452f99c23ef07a7f58bbb16d1f86c6be756f7c9b05c8433a90cdedb528L3191 from

			case 0xd7: // i_trans
				m_regs.b[AL] = GetMemB( DS, m_regs.w[BW] + m_regs.b[AL] );
				CLK(5);
				break;

to

			case 0xd7: // i_trans
				m_regs.b[AL] = read_byte(default_base(DS0), m_regs.w[BW] + m_regs.b[AL]);
				clk(5);
				break;

However, GetMemB with DS as first parameter also appears to allow overrides:

inline uint8_t v30mz_cpu_device::GetMemB(int seg, uint16_t offset)
{
	return read_byte( default_base(seg) + offset );
}