Opened 13 hours ago

Last modified 12 hours ago

#295 new enhancement

Prelude Rework (New Header for Regular Declarations)

Reported by: ajbeach Owned by:
Priority: major Component: cfa-cc
Version: 1.0 Keywords:
Cc:

Description (last modified by ajbeach)

As we put more code into the prelude some issues have come up. That is no section of the prelude (even builtins.cfa) is not regular Cforall code. All of them have various special linkage-specifiers set, at the very least Builtin, which changes the calling conventions of a function and changes auto-generation rules.

Creating a new part of the prelude for these declarations would mean that Cforall declarations can be moved to or from this header from the library without any (or at least less) rewriting.

To do this:

  • Add a new prelude file (call it cfa-builtins, cfa-extras, autoinclude or something else) and move regular declarations - that are just Cforall definitions we think you should not have to include to use - over to it.
  • Update automake to update these files and include them in distribution (this is the current issue).
  • Split the Builtin linkage flag into two, one that marks is part of the prelude (the entire prelude, not the single file) and one that says it just use the lower level calling convention.
  • Parse the new file with the Cforall flags set, with the "is in prelude" flag set but not the "use lower calling conventions" flag.

Change History (2)

comment:1 Changed 13 hours ago by ajbeach

Description: modified (diff)

comment:2 Changed 12 hours ago by ajbeach

I have looked over the current contents inside builtins.c (from which builtins.cfa is generated) and I believe I know which ones can move and which can stay (since I never got this working this is all untested):

Stay in builtins:

  • Destructor - This is the biggest example of something that should not move, it is involved in code generation and we want to to be as low level as possible to help with code generation.
  • Exception / Virtual - Core code actually written in C so using the lower level interface reflects that more accurately.
  • generators - The type definition would be treated differently and would have auto-generated functioned added.
  • is_value - Possibly could move, but considering it may replace object type, keeping it in the low core makes sense.
  • intptr - This needs that exact linkage to be code-generated properly.

Move to new file:

  • exit & abort - Nothing special about these, they are almost C functions but seem to implemented in Cforall somewhere.
  • identity - This is just a Cforall function made widely available.
  • Increment / Decrement / Not - Although operators feel more primitive, these are not, and these are just handy generic wrappers to build out your collection of operators. With bodies to attempt for inlining.
  • Power / Exponent - Same as above, except some of these are too big for inlining and the bodies have been moved.
  • Enumerations - A lot of code, some is low level enumeration operators and some higher level ones, including non-operator code and a lot of attempts to inline things. But it is all just C.
Note: See TracTickets for help on using tickets.