10. Miscellaneous notes

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

10.1 Description language notes
10.2 CGEN architecture notes
10.3 COS notes
10.4 RTL notes
10.5 Guile implementation notes
10.6 Code generation notes
10.7 Machine generated files notes
10.8 Implementation language notes

10.1 Description language notes

• timing support

  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.

• organization of cpu description

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

10.2 CGEN architecture notes

• compiled form of description in libcgen

  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.

• function-style attributes

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

• importance of description language

  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.

10.3 COS notes

• elm-xget, elm-xset

  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.

10.4 RTL notes

• Where's strict_lowpart? Where's foo?

  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.

• boolean values

  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.

• #f to denote "unspecified" values

  Sometimes () is used to specify "unspecified" values. Other times #f is used. Should standardize in #f.

• ifield assertions

  Perhaps these should be renamed to "constraints". "ifield-assertion" sounds clumsy.

10.5 Guile implementation notes

• Remaining todo is to complete switchover from "errtxt" (a string) in .cpu file reader support to "context" (a <context> object).

• Remaining todo is to complete switchover of naming functions from "prefix:function" to "prefix-function". One reasonable naming style is "prefix-verb-noun". I like it.

• Slib uses "prefix:foo" for "internal" routines. Maybe that would be a better choice than the current "-prefix-foo" style.

10.6 Code generation notes

• foo

10.7 Machine generated files notes

• In the end I think the best thing is to build the machine generated files when the tools themselves are built (same as gcc's gen* -> insn* files).

10.8 Implementation language notes

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 prefered 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 prefered 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.