Changes between Version 4 and Version 5 of Soclib Cc/Design Guide
- Timestamp:
- Mar 25, 2010, 2:50:26 PM (15 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Soclib Cc/Design Guide
v4 v5 4 4 == Why ? == 5 5 6 === We use a lot of tricky things things === 6 We use a lot of tricky things things: 7 7 8 8 * Different SystemC backends (SystemC-OSCI, SystemCASS, SoCView) 9 9 each of them is a different implementation of the same LRM, and 10 10 yields incompatible objects 11 11 * Metadata-based component definition, including used source files. 12 Components are not necessarily implemented in an unique file, but 13 may be scattered through different files, metadata does the glue. 12 14 * Templated classes. The usual way of using templated code is to 13 15 put all code in .h, having template code emitted at use in main C++ 14 file. 15 16 file. [[BR]] 16 17 This is good for small utilities, but SystemC modules may 17 18 be more than 1000 lines-long, and more that 40 of them may be used 18 19 in a topcell. This may yield a single translation unit with more than 19 20 50000 lines of code, heavily templated. This implies some usage issues 20 (compiler getting out of memory, unreasonnable compile times) 21 21 (compiler getting out of memory, unreasonnable compile times). [[BR]] 22 22 Therefore we need two features: 23 23 * Separate implementation: Put template class definition and implementation 24 24 in two separate files. Compile them separately. 25 25 [[BR]] 26 26 This implies template code must be explicitely instanciated with some 27 27 `template class Foo<parameters>;` code. It has to be done automatically. 28 28 * Object reuse: Once modules built separately, we can put objects 29 29 in a global repository and use the in a cached way. 30 31 30 * Different build modes (debugging, profiling release, others ??) 32 31 33 == = Reuse of current tools ?? ===32 == Why not reuse existing tools ? == 34 33 35 34 This could be seen as reimplementing make, or even SCons, and this is 36 not totally false. This is all about flexibility, and user-input 37 readibility. 35 not totally false. But we added other features: 36 * Template instantiation 37 * Separate source enumeration 38 * Object caching 38 39 39 40 There is no build tool known out the which does object caching and 40 41 template instantiation at the same time. Even if current build tools 41 42 may be enhanced to do the job, this is not an easy task. 43 Moreover, resulting code would be a kludge. 44 This is all about flexibility, and user-input readability. 42 45 43 This very tool has been implemented as a `make` wrapper before, 44 generated Makefiles were unreadable (all templates parameters in the 45 middle, ...), and it did not work so well. 46 Soclib-cc has been implemented as a `make` wrapper before, 47 it was not usable: 48 * generated Makefiles were unreadable (all templates parameters in the middle, …) 49 * it did not work so well (make interprets `:` a special way, and escaping is nearly unusable) 50 * the code generator was a big ugly piece of software 51 * we still had to do `.sd` file indexation. 46 52 53 = Design = 47 54 48 = Configuration = 55 [[Image(soclib-cc.png,nolink)]] 49 56 50 In order to compile SoCLib objects, we need: 51 * a working SystemC installation 52 * a working GNU-C++ compiler 57 = Usage = 53 58 54 Soclib-cc processes three files in order: 55 1. ''soclib-dir]''`/etc/soclib.conf` 56 1. `~/.soclib/global.conf` 57 1. `./soclib.conf` 58 59 These files contain multiple concurrent configurations for building 60 SoCLib. One of them will be chosen (explicitely) as the default 61 one. Others may be used on demand (through command-line or local 62 configuration file) 63 * File ![1] is installation-global. It should be modified by the 64 administrator for a network-wide configuration. 65 * File ![2] is useful for a developper's own configuration. This 66 allows to use a local development branch of a local SystemC, ... 67 * File ![3] is directory-local, this allows to choose different 68 flavours of previously declared configurations 69 70 See SoclibConf for a usage guide to these files. 71 72 == Usage == 73 74 Soclib-cc may be used two ways: 59 Soclib-cc may be used three ways: 75 60 * As a compiler wrapper. It will just be a CXX wrapper, handling 76 61 compilation or linkage on demand. This can be useful for external 77 Makefile integration. 62 Makefile integration. (the `-c` option) 63 * As a component compiler (the `-1` option) 78 64 * As a complete platform compiler. From an ad-hoc platform definition 79 65 (wrappers can be written to accept other formats), the complete 80 simulator will be compiled. 66 simulator will be compiled. (the `-p` option) 81 67 82 68 Try running `soclib-cc -h`. 83 84 === As a compiler ===85 86 The usual way:87 88 {{{89 $ soclib-cc -c -o obj.o file.cc90 $ soclib-cc -o sim obj.o ...91 }}}92 93 === As a platform compiler ===94 95 {{{96 $ soclib-cc -p platform_def97 }}}98 99 == Global flags ==100 101 -v::102 Print command lines103 -q::104 Dont say anything105 -m MODE::106 Change compilation mode (release, debug, prof)107 This changes in an homogenous way the building108 109 110 == Object repository ==111 112 As objects can be reused between builds, or even between platforms, we113 may want to place objects in a global repository.114 115 Default repository is in current directory, in '$(SOCLIB)/repos/'. If you want,116 you can specify another absolute path in configuration.