Re: Super-H machine language issues
[email protected] (Valeriy E. Ushakov) Fri, 29 Oct 2010 23:03:58 +0000 (UTC)
| Newsgroups | gmane.os.netbsd.ports.dreamcast |
|---|---|
| Message-ID | <[email protected]> |
der Mouse <[email protected]> wrote: > Page 283, describing FSQRT, says the PR=1 version of FSQRT is encoded > as 1111nnnn01101101, in sharp contrast to the way most PR=1 > instructions use only three bits for a register number, forcing the low > bit (usually to 0, occasionally to 1). Is this a typo, and it should > really be 1111nnn001101101, or is this an exception to the usual > pairing of registers when doing double-precision floating-point? As Marcus already pointed out, it's a typo on the instruction description page, but it's moot anyway, since "n" in DRn is always even, "nnnn" is the same bit pattern as "nnn0". E.g. $ cat test.s .text .globl foo foo: fsqrt fr0 fsqrt dr0 rts nop $ as --isa=sh4 -o test.o test.s $ objdump -d test.o test.o: file format elf32-shl-nbsd Disassembly of section .text: 00000000 <foo>: 0: 6d f0 fsqrt fr0 2: 6d f0 fsqrt fr0 4: 0b 00 rts 6: 09 00 nop Note that objdump disassembles both instructions as "fsrqt fr0", since you really can't tell from the bit-pattern. My guess is that with FPSCR.PR=1 the least significant bit of "nnnn" is just ignored (can't really test what happens if fsqrt fr1 is executed in double-precision mode, since NetBSD doesn't support sh4 FPU :) -uwe