Specification issues

At the suggestion of David Hopwood, I have recently read the C--
specification with some care. I would be tempted to use C-- for the BitC
project, and I want to say that this is an EXCELLENT piece of work.

That said, there are some shortcomings that I noticed in the current
specification. Most are minor, and nearly all can be easily addressed.
Many are identified already at some point in the specification.

Let me clarify that "minor" is not the same as "unimportant". If we are
to use C-- for BitC, all of these would ultimately need to be addressed.
In some cases we could wait a while, and I have marked these as
[Deferable]

Some of my issues may result from ambiguity about the mission bounds of
C--. If C-- is intended purely as a vehicle for code generation and
runtime interaction, many of these issues are just a matter of
clarification of intent. If C-- is intended to provide more general
optimization, then I think that some of this will eventually warrant
consideration.

Congratulations on such a good job.

Respectfully,


Jonathan Shapiro
Johns Hopkins University


Specification Issues:

+ The specification hints that C-- is entitled to do certain
  optimizations, notably including CSE and presumably including
  strength reduction and code hoisting if serious loop optimization
  is contemplated.

  If so, it is a deficiency in the C-- design that the front end
  cannot prohibit rearrangement of computational flow. I'm thinking here
  about numerical analysis codes, where the front end has carefully
  preserved a user-provided statement of computation order, and the back
  end must not rearrange this inappropriately. Such instructions can
  be reordered, and existing computations can be reused, but the
  expression tree may not be computationally rearranged to expose
  opportunities for CSE (though in all cases I know of, arguments to
  +, -, and * can safely be swapped for purposes of CSE discovery).

  Perhaps the intention was to restrict such optimizations to address
  expressions. If so, then my concern is withdrawn but this needs to
  be stated more clearly.

  If it is indeed intended to allow the back end this latitude, then
  some mechanism to prevent mishandling is required.

+ In order for debugging and related information to be meaningful,
  the specification needs to be clear about the limits of code motion.
  I would suggest a block-structured barrier construct.
  Regardless of debugging, the specification needs to be clearer about
  the degree of code motion that the C-- back end is entitled to
  undertake.

+ If loop optimizations are contemplated, then I question the
  wisdom of removing loop primitives from the language. Perhaps
  the state of the art has changed, but my experience was that
  loop rediscovery was painful, and that you really want to do
  this to guide the optimizer in attempting strength reduction,
  hoisting, and so forth.

  If I misunderstand the degree of intended potential optimization,
  perhaps a statement clarifying the bounds of the C-- mission might
  clarify things.

Debugging:

+ The current #line directive is horribly bad. We would have killed it
  at Bell Labs 20 years ago if we could have figured out how to do so
  compatibly. Don't replicate our error purely for the sake of
  verisimilitude. ADD A CHARACTER OFFSET! Allow -1 for "unspecified".

+ A directive is needed to allow (line, offset, file) information
  to be associated with labels so that source locations of labels
  can be accurately represented.

+ Since register selection is deferred to the C-- implementation,
  serious debugging support requires that the C-- compiler emit
  detailed location maps for variables, of the form:

    (PC start, PC end, variable, location)

  This can be represented compactly, but lesser information
  is insufficient for debugging in the face of code rearrangement.

  Such n-tuples should be present for all live addresses. The
  absence of a statement of location should be interpreted by
  the debugger as a statement that the variable is not live.

  Unfortunately, I see no way to emit this information from
  any place other than the back end.

Minor Items:

+ Floating point literals need to be fixed. Support for a 128 bit
  floating point representation should be supported, and support
  for rounding modes needs to be implemented. [Deferable]

  Aside: nobody with any brains uses extended mode if quad is
  available. The user mentality appears to be "when double isn't
  good enough, use the biggest thing available." Also, most
  processors do not do extended mode at all.

+ BitC would tremendously benefit from support for unicode literals.
  It would be entirely sufficient if we simply encoded them using
  octal escapes, but I suspect it is desirable to have distinguished
  character and string types for these. I don't see how to do this
  without taking a position on encoding. The right position is UTF-8,
  not the screwed up Java/C# double byte code point screwup -- but
  the mere fact that I need to say so serves to illustrate why this
  is a hairball.

  Perhaps it is simpler here, because the backend really doesn't
  need to understand the literal content. It might be sufficient
  for the front end to qualify the literal syntax for strings; the
  issue here is the need to know which NUL characters in the string
  are significant.

+ I suggest that all string literals be optionally length prefixed.
  Length in *bytes* is sufficient (and avoids unicode hassles). This is
  comparable to the .ASCII/.ASCIIZ distinction.