Changes between Version 11 and Version 12 of Soclib Cc/Design Guide

Timestamp:

Mar 30, 2010, 3:08:39 AM (15 years ago)

Author:

Nicolas Pouillon

Comment:

--

Soclib Cc/Design Guide

@@ -11 +11 @@
  * Component indexation in the library tree
  * Parametrization of source files
+   (about C++, it means templated code)
  * Build of all these files
+ * compile all these with different SystemC implementations
+ * compile all these with different compilation modes (debug, release, profiling, …)
+ * without having to change build files
 
-We also want to be able to compile all these with different SystemC implementation
-and different compilation modes (debug, release, profiling, …) without having
-to change build files.
-
-As virtual prototypes
-may be huge but users always use the same parameters, we would like the
-following additional features:
- * Parallel compilation
- * Object caching (ccache could be an option)
-
-As we speak about C++, parametrization of source files uses templated code.
+Additional features:
+ * Parallel compilation (virtual prototypes may be huge)
+ * Object caching (users nearly always use the same parameters — ccache is be an option)
 
 == Why ? ==
@@ -31 +27 @@
  * Different SystemC backends (SystemC-OSCI, SystemCASS, SoCView)
    each of them is a different implementation of the same LRM, and
-   yields incompatible objects
+   yields incompatible objects, thus objects have to be in separate
+   directories in order to be able to reuse objects without conflicts
  * Metadata-based component definition, including used source files.
    Components are not necessarily implemented in an unique file, but
@@ -38 +35 @@
    put all code in .h, having template code emitted at use in main C++
    file. [[BR]]
-   This is good for small utilities, but SystemC modules may
+   This is good for small libraries (like STL), but SystemC modules may
    be more than 1000 lines-long, and more that 40 of them may be used
    in a topcell. This may yield a single translation unit with more than
    50000 lines of code, heavily templated. This implies some usage issues
    (compiler getting out of memory, unreasonnable compile times). [[BR]]
-   Therefore we need two features:
-   * Separate implementation: Put template class definition and implementation
+   Therefore we need two more features:
+   * Separate implementation: Put template class definition (header) and implementation (.cpp)
      in two separate files. Compile them separately.
      [[BR]]
-     This implies template code must be explicitely instanciated with some
+     This implies that the C++ templates must be explicitely instanciated with some
      `template class Foo<parameters>;` code. It has to be done automatically.
-   * Object reuse: Once modules built separately, we can put objects
+   * Object reuse: Once modules are built separately, we can put objects
      in a global repository and use the in a cached way.
  * Different build modes (debugging, profiling release, others ??)
@@ -55 +52 @@
 == Why not reuse existing tools ? ==
 
-There is no build tool known out there which does object caching and
-template instantiation at the same time. Even if current build tools
+There is no known build tool out there which does object caching and
+template instantiation at the same time.
+
+Even if current build tools
 may be enhanced to do the job, this is not an easy task.
 Moreover, resulting code would be a kludge.
-This is all about flexibility, and user-input readability. 
+Soclib-cc has been implemented as a `make` wrapper before,
+it was not usable:
+ * generated Makefiles were unreadable (all templates parameters in the middle, …)
+ * it did not work so well (make interprets `:` a special way, and escaping is nearly unusable)
+ * the code generator was a big ugly piece of software
+ * we still had to do `.sd` file indexation
+ * we still had to emit template instantiation code
 
-This could be seen as reimplementing make, or even SCons, and this is
+Soclib-cc could be seen as reimplementing make, or even SCons, and this is
 not totally wrong. But we added other features:
  * Template instantiation
@@ -67 +72 @@
  * Object caching
 
-Soclib-cc has been implemented as a `make` wrapper before,
-it was not usable:
- * generated Makefiles were unreadable (all templates parameters in the middle, …)
- * it did not work so well (make interprets `:` a special way, and escaping is nearly unusable)
- * the code generator was a big ugly piece of software
- * we still had to do `.sd` file indexation.
+This is all about flexibility, and user-input readability. 
 
 == Compilation flow ==