Subject: publishing
From: Keunwoo Lee (klee@cs.washington.edu)
Date: Mon Jun 04 2001 - 22:09:15 PDT
In one line: dynamic scalar arrays work, and some output passes gmake.
towers runs (but does not pass gmake, obviously) on both o0 and o1. Some
other test cases both build and pass gmake. Details follow.
----------------------------------------------------------------------
LOWERING
+ Dynamic arrays of scalars are lowered and going through g++. Notes:
+ Added an InitScalarArrayElemsNode, with the obvious semantics.
Handy for initializing an array, so we don't have to generate a
loop during lowering. Will probably not generalize to arrays of
compounds.
+ I added an initialization macro INIT_SCALAR_ARRAY_ELEMS, to
implement the above node. The macro I currently have just
generates an in-line for loop, which works under g++ but may not
under other compilers; plus, it may lead to code bloat. We should
fix this with a macro-generated call to an initialization
function.
+ Added some rep checking for InitScalarArrayElemsNode.
+ Partly to support the above, I changed alloc nodes so that there is
now a FixedMallocNode (which is the one I now use for fixed arrays)
and a regular MallocNode, whose size can vary at runtime. Both
ultimately codegen to calls to the MALLOC_{bits,bytes,words} macros,
but MallocNode take a (possibly) dynamic scaling factor as an incoming
dataflow edge. This also implies extensions to the hierarchy of
RepSizes: there is now a RuntimeSpecifiedRepSize, in between RepSize
and SpecifiedRepSize, which only knows what unit size it uses but
does not know what the count of those units is---see
reps-helpers.cecil.
----------------------------------------------------------------------
INFRASTRUCTURE
+ Fixed the last few codegen-related obstacles to getting trivial code
through gcc/make:
+ Changed some stuff in wil-codegen-c, so various kinds of required
decls get written to various header/body files on output.
+ Fixed a bug where file-local main function names weren't
getting mangled properly, so you had names like "void test-base_main()"
generated. No more.
+ Fixed the last makefile-related obstacles to getting trivial code
through gcc/make:
+ Copied compileDate.c from runtime/pic/src/ to runtime/wil/src/. I
haven't examined closely what it's for, but it seems to be required
by runtime/wil/makefiles/ApplicationMakefile as a minor hack to make
parallel makes work right.
+ Changed runtime/wil/src/Makefile and runtime/wil/makefiles.* so
that they work under gmake on Linux and Solaris. Among other
things, the -L option is not working properly for me under g++/GNU
ld, so I explicitly specify the complete path to the runtime library
file. I also renamed the library from runtime.a to libwilruntime.a
to be more consistent with Unix conventions.
+ The previous points do not imply that tests/test-base.wil makes it
through gcc. However, smaller programs will. I have put a
test-minimal.wil file in tests/ which is about the most interesting
program I can currently write that runs through make and (I think)
executes correctly. Eventually test-minimal will converge with
test-base and we will get rid of test-minimal. (In the even longer
term, test-base.wil should converge with full-test-base.wil, but
things like multimethod dispatch and local method specializers are
pretty far off.)
+ Added NOOP_COMMENT(x, comment) macro to WIL-defs.h. Useful for tracking
the codegen of operations for which I am producing noops.
----------------------------------------------------------------------
TRIVIA
+ Added new_lowered_rep_chain to rep-chain.cecil, so I wouldn't have
to write new_rep_chain(foo_rep, foo_rep) all the time.
----------------------------------------------------------------------
UP NEXT
The next thing I'm going to tackle is nesting of composite objects.
This will include a notion of initializing a bunch of data at an
offset from a base pointer. Wish me luck.
Also up next is bringing back "new var", which I made illegal in my
last commit. In fact, "new var" has a semantics that makes sense: the
var affects the mutability of the allocated object, for those kinds of
objects that do not have other syntactic mechanisms to define their
mutability (e.g., arrays have their own way of saying they are "var").
Anyway, more on this in my next commit, hopefully.
_______________________________________________
Cecil mailing list
Cecil@cs.washington.edu
http://majordomo.cs.washington.edu/mailman/listinfo/cecil
This archive was generated by hypermail 2b25 : Mon Jun 04 2001 - 22:10:05 PDT