| [Top] | [Contents] | [Index] | [ ? ] |
‘libcgen’ currently doesn't exist, but that was the original plan.
I'm just trying to solicit input here. Maybe these questions will help get that input.
Actually, this can be reduced even more by creating copies of an instruction specialized for all the various inputs.
The actual results depend, of course, on the exact mix of target instructions in the application, what instructions the host cpu has, and how efficiently the rest of the simulator is (e.g. floating point and memory operations can require a hundred or more host instructions).
This hasn't actually been implemented so there is some hand waving here.
Note that there are other uses for such a program modification tool besides profiling.
Today this is libopcodes to some degree.
By this I mean analyzing the C and understanding what it's doing.
The simulator currently uses elements of the opcode table since the opcode table is a nice central repository for such things. However, the assembler/disassembler isn't part of the simulator, and the portions of the opcode table can be generated and recorded elsewhere should it prove reasonable to do so. The CPU description file won't change, which is the important thing.
Read-Evaluate-Print-Loop
While RTL stands for Register Transfer Language, it is also used to denote the CPU description language as a whole.
It is possible to produce a reference manual from ‘.cpu’ files and such an application wouldn't be a bad idea.
It would be reasonable to have a short form and a long form of comment. Either as two entries are as one entry with the short form separated from the long form via some delimiter (say the first newline).
??? This is true in RTL, though some apps add symbols and convert case that can cause collisions.
Yes, attributes can have attributes.
FIXME: Using "cpu" in "cpu-family" here is confusing. Need a better name. Maybe just "family"?
A term borrowed from the book on the Bulldog compiler and perhaps other sources.
Whether to also provide a way to specify instruction formats is not yet clear. Currently they are computed from the instructions, so there's no current *need* to provided them. However, providing the ability as an option may simplify other tools CGEN is used to generate. This simplification would come in the form of giving known names to the formats which CPU reference manuals often do. Pre-specified instruction formats may also simplify expression of more complicated instruction sets. Providing instruction formats may also simplify the support of really complex ISAs like i386 and m68k).
Positional specification simplifies instruction description somewhat in that there is no required order of fields, and a disjunct set of fields can be referred to as one. On the other hand it can require knowledge of the length of the instruction which is inappropriate in cases like the M32R where the main fields have the same name and "position" regardless of the length of the instruction. Moving positional specification into instruction formats, whether machine generated or programmer specified, may be done.
A scalar instruction field is a simple ifield (not a multi or derived ifield), or a multi-ifield consisting of only simple ifields.
Like all rtx, the full syntax is
(member [(options)] [member-mode] ifield-name (number-list [(options)] [numlist-mode] value1 [value2 ...])),
but ‘options’ and ‘mode’ are not really useful here.
‘member-mode’ is ‘BI’, since the result is a boolean value.
For complicated instruction sets this is a lot of typing. However, macros can reduce a lot of that typing. The real question is given the amount of information that must be expressed, how succinct can one express it and still be clean and usable? I'm open to opinions on how to improve this, but such improvements must take everything CGEN wishes to be into account. (*Note: Of course no claim is made that the current design is the be-all and end-all or that there is one be-all and end-all.)
The restriction can be relaxed by saying the first blank is the one that separates the mnemonic from its operands.
Syntactic form pmacros don't pre-evaluate their arguments. See section Syntactic forms.
A "free variable",
as defined here, is one that is not already bound, be it to
parameter, macro, or local variable within a macro.
Note that to pmacros, cpu description file elements like
reg, sequence, VOID, etc. are just symbols;
they have no special meaning.
This behaviour will go away eventually, do not rely on it.
A temporary simplifying assumption is to treat all memory identically. Being able to specify various kinds of memory (e.g. on-chip RAM,ROM) is work-in-progress.
This doesn't include fields like multi-ifields.
A profound aversion to typing causes me to often provide brief names of things that get typed a lot.
Normal for some anyway, certainly each person will have their own preference.
Although this hasn't been implemented yet.
As the number of source files grows the entire layout may be changed, but until then this is how things are.
This dates from a time when CGEN supported being compiled with Hobbit. That support is gone, though something else may take its place.
not true for <arch> but will be RSN
modes aren't recorded here, should they be?
| [Top] | [Contents] | [Index] | [ ? ] |
This document was generated by Doug Evans on January, 28 2010 using texi2html 1.78.