| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This chapter is a repository of miscellaneous notes that belong elsewhere or nowhere. They're here because I want them written down, for now anyway, and I'm not sure where else to put them. There may be duplication here with things elsewhere in the docs. I'm not bothering to ensure there isn't. It's better to have things written down twice than not at all. If there is a conflict between notes here and elsewhere, check the chronology. I may have changed my mind. If not, the situation may be complicated and I don't have a strong opinion on what's right. No claim is made that these notes represent my complete opinion. (Hmmm... lessee what other caveats I can throw in here ... :-)
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The current implementation of timing (aka pipeline, function units, etc.) support is a quick hack in order to achieve useful numbers out of the simulator. It is intended to be replaced with something a lot more sophisticated. Remember to keep in mind cgen's goal of application independence when designing the new version. For example, it must handle things like code scheduling in a compiler (where speed of analysis is not critical) to scheduling in a dynamic compiler (where speed of analysis is critical). It must also handle semi-accurate to fully-accurate cycle counting in simulators (where the former might trade off accuracy for speed which one wouldn't do in the latter, assuming there is a trade-off to be made). It must also handle the representation and handling of pipelines with program visible hazards.
One thing that may not be apparent is that the description language doesn't preclude one item (say an insn) from having its definition spread over several files. One example would be to leave the timing elements unspecified in the "main" entry of an insn, and then have a machine-specific file providing timing characteristics, etc.
One can even leave the semantics to be defined elsewhere. The `=' insn format prefix is not currently used very much (no need). It might also need better documentation.
A possible break-up of an item's description into several files should be generally supported (where reasonable).
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The current compiled form of the cpu description has been focused on two applications: opcodes and simulator. No doubt there are things present that will present problems to future applications. One thing on the todo list has been to record semantics with the compiled form, probably as bytecode. Maybe it would make sense to record the entire cpu description as a kind of bytecode. This would allow apps to instantiate it for the task at hand as they please.
Attributes currently only support static (compile-time computed) notions. They should also support run-time computed values. The way to do this is to record such attributes as bytecode and lazily (or not lazily) evaluate them at runtime, perhaps caching the results. It might make sense to record all attributes this way (though I currently don't think so).
When hacking on cgen, the description language takes priority over implementation. That cannot be stressed enough. When faced with choices of what to do, put the elegance, maintainability, and application independence of the description language first. Implementation will almost always take shortcuts due to application specific requirements. Theoretically the description language won't have to; at least that's where the effort in application independence should be put.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
These procedures are quick hacks and should be avoided. Existing uses should be replaced. Where they're used it's either because of laziness or because I wasn't sure whether I wanted to allow global access to the element, so using an easily grep-able hack let's me find them and revisit them.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Elements of gcc's rtl like strict_lowpart, pre_inc, etc. aren't in cgen's rtl only because thus far there hasn't been a compelling need for them. When there is a compelling need they'll be added.
Sometimes #f/#t is used for boolean values.
However the "boolean" mode BI has values 0 and 1.
Which one is in use is context dependent.
Not sure there is a problem but it should be revisited.
Sometimes () is used to specify "unspecified" values. Other times #f is used. Should standardize in #f.
Perhaps these should be renamed to "constraints". "ifield-assertion" sounds clumsy.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
In the end I think the implementation language (or the Guile implementation) will have to change. If one compares the speed of gcc's gen* file generators vs cgen's, and one envisions the day when machine generated files are built at build time, then I think the user community will require similar speed in file generation. Guile isn't fast enough. And while Guile+Hobbit may be, for the one-time builder the time taken to compile Hobbit, run it, and compile the result, will appear to swamp any gains. There is also the additional burden of building Guile first (though with my preferred Guile implementation I'm _hoping_ that wouldn't be a problem).
The pragmatic choice is C. Blech.
A better choice would be C++ but then that would obviously place a requirement on having a C++ compiler available in order to build binutils, for example (assuming machine generated files are built at build time).
Java would also be a better implementation language than C [an interesting experiment would be Kawa]. But it's worse as a pragmatic choice than C++.
My preferred choice is a small-and-fast subset of Guile that gets distributed with binutils, gdb, etc. IMO Guile is too bloated and unmaintainable for the casual maintainer (hacking on its innards requires too steep a learning curve, and is one that is easily slipped back down should one step away from it for too long). If those can be fixed and the speed of cgen's file generation can be made acceptable, then that is the path I would choose.
In making the choice people need to look forward rather than look backward. We're finally switching the GNU tools to ANSI C. If the host doesn't provide an ANSI C compiler the user is expected to get one (GCC). Well, G++ is available on most if not all hosts of concern, so in this day and age requiring C++ in order to build binutils isn't as much of a burden as it use to be. Cgen is a forward looking design. At its heart is a goal to close no doors on future uses. That's a pretty lofty goal. Forcing people to achieve that goal with C because of pragmatic concerns is unjustifiable, IMO.
Note that changing the "implementation language" does _not_ mean Guile cannot or will not be used for various things! I think Guile should continue to be used for prototyping as well as certain applications.
| [ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This document was generated by Doug Evans on January, 28 2010 using texi2html 1.78.