@c Copyright (C) 2000 Red Hat, Inc.
@c This file is part of the CGEN manual.
@c For copying conditions, see the file cgen.texi.

@node Miscellaneous notes
@chapter Miscellaneous notes
@cindex 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 ... :-)

@c ??? Shouldn't have to append " notes" to every menu entry.
@c It's done because some entries collide with menu entries in other
@c chapters and texinfo doesn't like that (complains or crashes).

@menu
* Description language notes::
* CGEN architecture notes::
* COS notes::
* RTL notes::
* Guile implementation notes::
* Code generation notes::
* Machine generated files notes::
* Implementation language notes::
@end menu

@node Description language notes
@section Description language notes

@itemize @minus

@item 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.

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

@end itemize

@node CGEN architecture notes
@section CGEN architecture notes

@itemize @minus

@item 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.

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

@item 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.

@end itemize

@node COS notes
@section COS notes

@itemize @minus

@item 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.

@end itemize

@node RTL notes
@section RTL notes

@itemize @minus

@item 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.

@item boolean values

Sometimes #f/#t is used for boolean values.
However the "boolean" mode @code{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.

@item #f to denote "unspecified" values

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

@item ifield assertions

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

@end itemize

@node Guile implementation notes
@section Guile implementation notes

@itemize @minus

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

@item
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.

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

@end itemize

@node Code generation notes
@section Code generation notes

@itemize @minus

@item foo

@end itemize

@node Machine generated files notes
@section Machine generated files notes

@itemize @minus

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

@end itemize

@node Implementation language notes
@section 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.
