This is the mail archive of the
cgen@sources.redhat.com
mailing list for the CGEN project.
closing and re-opening CPUs in opcodes
- From: Graydon Hoare <graydon at redhat dot com>
- To: binutils at sources dot redhat dot com
- Cc: cgen at sources dot redhat dot com
- Date: Wed, 1 May 2002 18:12:49 -0400
- Subject: closing and re-opening CPUs in opcodes
- Reply-to: graydon at redhat dot com
Hi,
When doing multi-CPU simulation in sid, on cgen-generated CPU
cores, with --trace-disassemble, opcodes is called once per insn
to do the disassembly. If two calls come with different CPU
description handles, opcodes will *notice* this fact, via a
static handle it keeps in function scope telling it how it was
last called, and close/re-open the handle it's being called with.
This has a couple penalties associated with it. First, it reveals
a number of hidden memory leaks between CPU description open and
close (and I've not found all of them yet). Second, it is
actually quite expensive in terms of simulator cycles, since we
re-initialize a bunch of tables, rebuild assembly regexes, etc.
every time we re-open a CPU description.
When you run with large-ish blocks between CPU yields, this is
not too bad. When you run the CPUs in lock-step, to give a good
"simulated concurrency", it is intolerably slow (and quickly eats
all available memory). Is there any particular reason why, in
opcodes' "handle oriented" interface, we're closing and
re-opening? Shouldn't the handles isolate all the resources
they're responsible for?
I'll keep digging, but any additional insight would be
appreciated.
-graydon