The theme of toys runs through many of the tools related to LEGO. The original reason for the name is to relate to the PlayDoh architecture developed at HP Labs. The acronymic description for LEGO, Le Grand Optimisateur, was of course contrived after the fact.
Rebel is a textual representation of code, specified by HP Labs and designed with the PlayDoh architecture in mind. LEGO IR is organized based on Rebel structures.
LEGO IR is a code representation which consists of memory structures, rather than being written as text. Rebel can be parsed into LEGO IR structures, and LEGO IR can be written out as Rebel. Also, LEGO IR contains other information which is not representable in Rebel.
Lcode is a textual representation of code, specified by the IMPACT group at the Center for Reliable High-performance Computing at the University of Illinois.
Rebel formats the text portion of a program (as opposed to the static data) differently, with more information and opcodes belonging to the PlayDoh architecture. However, they share data segment formats and attribute specifications.
We use IMPACT and Elcor as a front-end for LEGO. IMPACT can take in C code (such as the SPEC benchmarks) and convert them to Lcode. Elcor can convert Lcode to Rebel, which we can use. Both compilers also can be used for tasks not yet present in LEGO, such as optimizations.
First read the introduction to LEGO IR, then go over the Users' Manual for LEGO IR. The other manuals can wait until you need them. All the manuals are available in the documentation page.
The difference stems from the way code is linked from a library into an executable. Static libraries (archives) are linked once, at compile time. Dynamic (shared) libraries are relinked every time an executable using them is run.
Executables using static libraries don't need to be relinked every time they are run since they carry the code around with them.
There are several advantages to dynamic libraries. Since the executable relinks the library for every run, it doesn't need to carry the code around, so programs are smaller. Also, if something internal to the library code changes (due to bug fixes, for example), or new library versions are released, the executables using the library do not have to be recompiled.
If you require absolute stability in your executables, either because they cannot tolerate any updates to the library or because the runtime for them spans a very long time (i.e., weeks or more), use static libraries. Otherwise (which is most of the time), you should definitely use dynamic libraries.
Sure. Keep in mind that most compilers, when given the choice, will link with dynamic libraries before static libraries. See the compiler documentation for ways to get around that. Usually, fully specifying a library as a compilation object (as opposed to using the -l switch, say) is enough.
yyparse is the flex/bison parser. It's required if your executable tries to call LegoRead anywhere. First be sure you are linking with libfl.a. If you are, make sure it is listed after the LEGO IR library (liblego), or yyparse won't be linked.
When a compiler links library code into an executable, it onlys grabs the code that is in demand at the time the library is handled. This economizes both link time and program size. The compiler runs through objects and libraries in the order that they appear on the command line, finding and resolving demands as they arise. The demand for yyparse comes from the LEGO IR library, but if libfl.a is listed before it, the demand hasn't arisen yet. So, the compiler skips yyparse.
_default_alloc_template and
get_dynamic_handler_chain. It used to work. What's wrong?You need to compile LEGO with gcc 2.8.1 now. It has a much better implementation of STL and reworked template support that LEGO requires. All of your code must be compiled with gcc 2.8.1, or else these errors will pop up.
You need to use the GNU version of as with gcc 2.8.1. NSTARTUP isn't
standard HP assembly. Type add gnu to enable that assembler
in your environment.
They are an easy and independent way of storing parameters. Something as complex as LEGO depends on a whole slew of parameters for different things it does. The knobs idea (adapted from IMPACT's parms) allows for an easy way to keep all the parameters together and easily changeable.
Well, you can, but there are several pitfalls to that. First, you have to update the declaration of a function everywhere every time you add an argument. This will require you then to recompile everything. With a knob, you just need to change function internals and plop a new knob into your knob files.
Also, having a whole bunch of command line arguments gets unwieldy very fast, so storing them in a nice neat knob file is easy. Plus, you can change parameters simply by switching knob files, rather than retyping a humungous command line.
Also, some parameters are required by the deepest darkest parts of LEGO, and without knobs you would have to pass them through many levels of function calls (unless you like making global variables, which you shouldn't).
Bearing all that in mind, you can pass new knob values on the
command line using the -K switch. The Knobs manual,
available on the documentation page, describes how.
NO. The global knobs file should not be changed unless you are adding a new knob for everyone's use. Instead, redefine the knobs in your own knob file, and those values will override the global ones.
The function knobs::Save will dump all the currently defined
knobs and their values to a file of your choice. You can peruse it to see
what is defined and what the values are. You can also use the output as a
knob file if you wish; it has the proper syntax.
Last modification of this page on 27 April 1998