1 Feb 2003 15:13
7 Feb 2003 15:40
Again: variable width instructions
Manuel Kessler <mlkessle <at> cip.physik.uni-wuerzburg.de>
2003-02-07 14:40:55 GMT
2003-02-07 14:40:55 GMT
Five or six weeks ago David Carney asked how to handle instructions with
fields beyond the usual instruction size, which is rather CISC-ish. While
Frank and Doug responded quickly, how to handle this situation, by
defining just fields starting at the next bit (and the trick to define
lsb0? to #f), he did not succeed. As he told me, he had to move on to
other things, and so got distracted.
However, I am in a similar situation, trying to accomplish more or less
the same thing. While for my microcontroller (Mitsubishi M16C, if anybody
is interested) instructions may be as short as 8 bits, with operands,
immediates and prefixes they may grow to up to 80 bits or so. I was able
to assemble and disassemble the first instructions with different
addressing modes (and correspondingly different lengths) by using
xxx-insn-bitsize of 32 (instead of the 8 as suggested in the documentation
for the smallest instruction), but for instructions even longer than that
my attempts were not successful. While I can define instruction fields
that late, I can not fill them with registers or immediates, this data
(register indices etc.) gets stuck in the first portion of the
instruction.
Doug mentioned the fr30 port as a guidline, which has a single instruction
taking a 32 bit immediate and thus being longer than the others. However,
this functionality seems to be gone. The same problem is there: The
immediate data does not get filled in the appropriate slot. I took this
file:
; test file for ldi32
ldi:32 $0x80000000, r0
nop
ldi:32 $0x00000000, r1
(Continue reading)
7 Feb 2003 22:06
Re: Again: variable width instructions
Jan Zizka <janzizka <at> yahoo.com>
2003-02-07 21:06:44 GMT
2003-02-07 21:06:44 GMT
Hi! I had the same problem. I'm porting binutils to DSP56800. Normal instructions have 16bits but eventually this may increase to 48 (3 words). I've solved it by defininig the immediate instruction fields as: (define-ifield (name f-imm16) (comment "16b imm data") (attrs) (word-offset 16) (word-length 16) (start 15) (length 16) (mode UINT) ) (define-ifield (name f-imm16w3) (comment "16b imm data in third word") (attrs) (word-offset 32) (word-length 16) (start 15) (length 16) (mode UINT) ) so when the word-offset is 0 it accesses first 16 bits (I have 16 bit insns base), when it is 16 then the next word etc.(Continue reading)
8 Feb 2003 15:13
10 Feb 2003 02:05
Re: Again: variable width instructions
Doug Evans <dje <at> sebabeach.org>
2003-02-10 01:05:09 GMT
2003-02-10 01:05:09 GMT
Hi.
Regarding the fr30 example:
; test file for ldi32
ldi:32 $0x80000000, r0
nop
ldi:32 $0x00000000, r1
nop
ldi:32 $0xffffffff, r2
nop
ldi:32 $0x7fffffff, r3
nop
.end
Things might actually be working ok, depending upon whether or not
$0x80000000, etc. are valid symbols. What's happening is that
gas is interpreting them as symbols ($ doesn't prefix constants in
fr30 assembler). If you had included -r in the arguments to objdump
you would have seen the following. Live and learn I guess. 
00000000 <foo>:
0: 9f 80 00 00 ldi:32 0x0,r0
4: 00 00
0: R_FR30_48 $0x80000000
6: 9f a0 nop
8: 9f 81 00 00 ldi:32 0x0,r1
c: 00 00
8: R_FR30_48 $0x00000000
e: 9f a0 nop
(Continue reading)
11 Feb 2003 14:42
Re: Again: variable width instructions
Manuel Kessler <mlkessle <at> cip.physik.uni-wuerzburg.de>
2003-02-11 13:42:27 GMT
2003-02-11 13:42:27 GMT
Thanks first to Doug and Jan for their helpful comments. On Sun, 9 Feb 2003, Doug Evans wrote: > Things might actually be working ok, depending upon whether or not > $0x80000000, etc. are valid symbols. What's happening is that > gas is interpreting them as symbols ($ doesn't prefix constants in > fr30 assembler). If you had included -r in the arguments to objdump > you would have seen the following. Live and learn I guess.(Continue reading)> Regarding problems specifying ciscy fields in m16c.cpu, Jan is right. > You (probably) want to use the full form of define-ifield for these. > It's unfortunate that I didn't create a shorthand version of the > full form of define-ifield, I think its absence has led to some confusion. > E.g. You don't need #lsb0 = #f, it just makes the abbreviated short forms > dnf and df [sic (*1)] work better. Yes, I have been playing with lsb0=#t and #f, and I think there is some problem with #t, possibly only in combination with little endian. Attached you will find my updated m16c.cpu file, which nearly works with xxx-insn-bitsize 16. As I need constant fields in the second byte, I probably cannot go down to 8 currently, but that's ok for me now. For testing, I defined some ifields with the full form, especially take a look at f-opc1b, which is an opcode part in the second byte. If I define it with word-offset 8 and start 5, the opcode part (0x2f) does not end up in the corresponding bits of the second byte, but gets added to the first byte! However, if I define it with word-offset 0 and start 13, the behaviour is correct?!? Interestingly enough, the nearly identical
11 Feb 2003 14:45
Re: Again: variable width instructions (fwd)
Manuel Kessler <mlkessle <at> cip.physik.uni-wuerzburg.de>
2003-02-11 13:45:02 GMT
2003-02-11 13:45:02 GMT
Sorry for disturbing again, of course I forgot the attachment(Continue reading)Thanks first to Doug and Jan for their helpful comments. On Sun, 9 Feb 2003, Doug Evans wrote: > Things might actually be working ok, depending upon whether or not > $0x80000000, etc. are valid symbols. What's happening is that > gas is interpreting them as symbols ($ doesn't prefix constants in > fr30 assembler). If you had included -r in the arguments to objdump > you would have seen the following. Live and learn I guess.
11 Feb 2003 21:19
[patch][rfa] <at> arch <at> _cgen_ifld_table
Dave Brolley <brolley <at> redhat.com>
2003-02-11 20:19:29 GMT
2003-02-11 20:19:29 GMT
Hi,
Stan Cox noticed the following when debugging a problem with one of our
internal ports. I've replaced the name of the port with ' <at> arch <at> ' and
' <at> ARCH <at> ' below:
-------------------------------------------------------------------------
I notice that <at> arch <at> -opc.c defines:
#define F(f) & <at> arch <at> _cgen_ifld_table[ <at> ARCH <at> _ ##f]
so it would seem as though the members of <at> arch <at> _cgen_ifld_table should
match those of enum ifield_type. However they do not always do so;
they seem to get out of sync for multi-ifields.
( <at> arch <at> -desc.c)
{ <at> ARCH <at> _F_CSRN_HI, "f-csrn-hi", 0, 32, 15, 1, { 0, { { { (1<<MACH_BASE), 0 } } } } },
{ <at> ARCH <at> _F_CSRN_LO, "f-csrn-lo", 0, 32, 8, 4, { 0, { { { (1<<MACH_BASE), 0 } } } } },
{ <at> ARCH <at> _F_CRNX_HI, "f-crnx-hi", 0, 32, 28, 1, { 0, { { { (1<<MACH_BASE), 0 } } } } },
{ <at> ARCH <at> _F_CRNX_LO, "f-crnx-lo", 0, 32, 4, 4, { 0, { { { (1<<MACH_BASE), 0 } } } } },
versus ( <at> arch <at> -desc.h)
, <at> ARCH <at> _F_CSRN_HI, <at> ARCH <at> _F_CSRN_LO, <at> ARCH <at> _F_CSRN, <at> ARCH <at> _F_CRNX_HI
, <at> ARCH <at> _F_CRNX_LO, <at> ARCH <at> _F_CRNX, <at> ARCH <at> _F_0, <at> ARCH <at> _F_1
---------------------------------------------------------------------
As it turns out, gen-ifld-defns does explitictely omit VIRTUAL and
derived ifields when generating <at> arch <at> _cgen_ifld_table and
gen-maybe-multi-ifield expects them to be omitted when indexing the
(Continue reading)
11 Feb 2003 21:41
Re: [patch][rfa] <at> arch <at> _cgen_ifld_table
Frank Ch. Eigler <fche <at> redhat.com>
2003-02-11 20:41:04 GMT
2003-02-11 20:41:04 GMT
Hi - brolley wrote: > [...] > This has been tested on fr30 and on our internal port. > Seeking approval to commit. Looks fine to me. Approving your patches seems like an unnecessary formality, given your understanding and history. Does someone see a need to avoid recognizing brolley within the maintainers list? - FChE
11 Feb 2003 22:21
Re: [patch][rfa] <at> arch <at> _cgen_ifld_table
Doug Evans <dje <at> transmeta.com>
2003-02-11 21:21:11 GMT
2003-02-11 21:21:11 GMT
Frank Ch. Eigler writes: > Approving your patches seems like an unnecessary formality, > given your understanding and history. Does someone see a > need to avoid recognizing brolley within the maintainers list? Since you're asking ... Yes and no. Even maintainers need their patches approved, or at least discussed, if the change is substantial. As long as there continues to be the proviso that substantial changes get discussed on the list first, sure. I realize that may have been implicit. Just making it explicit.
RSS Feed