Re: Super-H machine language issues

[uwe%stderr.spb.ru@localhost (Valeriy E. Ushakov)]

der Mouse <mouse%rodents-montreal.org@localhost> 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