This is the mail archive of the cgen@sources.redhat.com mailing list for the CGEN project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Again: variable width instructions (fwd)


Sorry for disturbing again, of course I forgot the attachment :-(

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. :-)

Feeling a little embarrassed, but who knows fr30 assembler anyway ;-)

> 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
definition of the register part in the second byte (which is obviously
not constant, but depends on the chosen register) is working both ways.

To make matters worse, in one combination of lsb0, word-offset and
xxx-bitsize (can't remember exactly, and am too lazy to reproduce, so
feel very free to ignore this paragraph), the assembled bytes were
correct, but objdump couldn't disassemble them back, so some information
was included in the assembler, but missing in the disassembler or vice
versa.

Anyway, there is a way to do it, so it's okay. The problem occurs if I go
to the variant including 8bit displacement, which is 24bit long
(negi8). If I leave the displacement field out (disp8), the two opcodes in
the first two bytes get assembled correctly, but naturally the
displacement is missing. If I include the displacement field in the
instruction definition, the displacement gets filled in the correct place
and the next instruction starts at the correct position 24bits later, but
the two opcode bytes get screwed up. More specifically, the opcode part
which belongs to bits 0-6 (lsb0=#t) of the second byte, vanishes
completely, as do bits 6-7 of the first byte, and bits 4-5 of the first
byte show up in their proper positions in the second byte.

So that's the current state of affairs. Feel free again to comment on the
attached m16c.cpu file.
 
> I went to savannah.nongnu.org and checked out and built an m16c toolchain
> (but using the m16c.cpu file you included in your message).

Thank you very much for getting this far!
 
> I can see some of the problems you're having.  For example,
> 
> 	neg.b 4[a0]
> 
> disassembles to
> 
>    0:	a2 2f 04 42 	*unknown*
> 
> but it's only a 3 byte insn.

It is clear that any unknown instruction gets disassebled as
base-insn-bitsize, but if it gets disassembled, then with the proper
length.

> You really do want to use the proper values of 8 for base-insn-size, etc.
> 
>   (default-insn-bitsize 8)
>   (base-insn-bitsize 8)
>   (default-insn-word-bitsize ???)
> 
> Off the top of my head I dunno what's a good value for
> default-insn-word-bitsize for the m16c.
> 
> Given that base-insn-bitsize is 8 you'll want to use the full form of
> define-ifield, or the macros that are in your m16.cpu file: dif and dnif (*2).
> 
> There's one more problem though.  Cgen current doesn't support ifields
> with constant values beyond base-insn-size.  There are hooks for this
> in various places, but no one has finished the work.  It's straightforward,
> more leg-work than brain-work.  I'll make a point of getting to it
> this week (can't promise an ETA, but we shall see).

Of course I do want the correct xxx-bitsize, but as I need the constant
ifields beyond 8 bits I (currently, at least) have little choice. 16 would
be fine, if I can make it work.

Thanks again for all the help up to now, but gratefuls as I am I will
still beg for more :-)

Ciao,
	Manuel

______________________________________________________________________
  
Dr. Manuel Kessler, Dipl.-Phys.

Institut fuer Aerodynamik und Gasdynamik
Universitaet Stuttgart
Pfaffenwaldring 21           ( ( ( ( ___________.^.___________ ) ) ) )
70550 Stuttgart / Germany                      _\I/_                
                                              /\_|_/\
Phone:      +49 711 685 3435                  \_(_)_/ 
Fax:        +49 711 685 3438                 ./     \.
E-Mail:     kessler@iag.uni-stuttgart.de               
WWW:        http://www.iag.uni-stuttgart.de/people/manuel.kessler
______________________________________________________________________


Attachment: m16c.cpu
Description: Text document


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]