* better use of disassembly hash table by mep port
@ 2009-12-20 9:04 Doug Evans
2009-12-21 19:25 ` DJ Delorie
0 siblings, 1 reply; 2+ messages in thread
From: Doug Evans @ 2009-12-20 9:04 UTC (permalink / raw)
To: Frank Ch. Eigler, dj, cgen
I think I understand the MEP port enough to have it starting using the
disassembly hash table better (rather than hashing every insn to the
same slot, blech).
The basics have always been there, we just need to extend it a little.
[Another way to go, of course, is to add a simulator-style decoder to
the disassembler. There's various reasons why I didn't do that in the
beginning. It'll probably be useful to add it some day.]
AIUI, different MEP ISAs use different opcode bits and so the hashing is
useless ... if one tries to hash *all* insns for *all* ISAs in *one*
table. But if one takes the current isa/mach/config into account when
doing the hashing and ignore insns that don't match it, I think a useful
hash is possible. Right?
[I'm assuming the chip doesn't do something excessively funky and that
for any particular isa/mach/config context there are *some* opcode bits
common to all relevant instructions for that context.] I gather the MEP
port doesn't do that because more parameters are used to decide whether
an insn is valid for the current context than what cgen currently uses
(which is isa/mach/endian). See mep.opc:mep_cgen_insn_supported.
If we enhance the disassembler's instruction recognizer hash table
builder to let the target record additional parameters to use to decide
when a new CGEN_CPU_DESC needs to be created, and let the target provide
routines to access/use that info, I think that's all that's needed.
Plus , of course, a hash function - I think the code can pick something
at runtime if the port doesn't provide one. E.g. pick all the bits that
are constant in the first instruction word. An N-stage hash could be
done for ISAs that have few common bits among all insns, but have more
common bits among groups of instructions. Maybe we could even
use/borrow the simulator's decoder-generator to drive it.
Comments?
Am I missing anything?
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: better use of disassembly hash table by mep port
2009-12-20 9:04 better use of disassembly hash table by mep port Doug Evans
@ 2009-12-21 19:25 ` DJ Delorie
0 siblings, 0 replies; 2+ messages in thread
From: DJ Delorie @ 2009-12-21 19:25 UTC (permalink / raw)
To: Doug Evans; +Cc: fche, cgen
> I think I understand the MEP port enough to have it starting using the
> disassembly hash table better (rather than hashing every insn to the
> same slot, blech).
MeP does that too? I mentioned m32c had that problem, and it was a
problem even with one specific ISA (the chip is weird as far as opcode
encoding goes). m32c is compounded by the explosion of opcodes caused
by the way cgen does variable-length insns.
My hash thoughts for m32c was to take each opcode, figure out which
bits are decodable for *that* opcode, and use those to put the opcode
into one or more hash entries. That allows us to use a wider set of
bits, thus fewer entries per bucket, while sidestepping the m32c's
decodable bits problem.
OTOH I've also started working on a non-cgen port of m32c.
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2009-12-21 19:25 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-12-20 9:04 better use of disassembly hash table by mep port Doug Evans
2009-12-21 19:25 ` DJ Delorie
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).