Related articles |
---|
new compiler metadata... cr88192@hotmail.com (cr88192) (2009-05-24) |
From: | "cr88192" <cr88192@hotmail.com> |
Newsgroups: | comp.compilers |
Date: | Sun, 24 May 2009 13:18:45 -0700 |
Organization: | albasani.net |
Keywords: | practice |
Posted-Date: | 24 May 2009 19:43:29 EDT |
well, anyways, maybe people here might be interested or have comment.
so, basically, I ended up eventually adding a "repository" for metadata, and
not quite what I had originally imagined. at first, I thought I would
implement a relational-database style structure, but this seemed like it
would be too awkward in general to work with, and so I never really got to
it.
eventually, I had ended up hacking a prior key/value system of mine, and
modified it to store the metadata (mostly by embedding a bunch of info in
the key name, and using it to fetch the value). however, this approach
produces long strings and so wastes lots of additional memory.
a more recent change had been to go over to an essentially heirarchical
structure, where a 'path' is used to address a group of key/value pairs
(note that a path may contain both key/value pairs, as well as sub-paths,
and each path has a "default" key as well, I represent in storage as '_').
note that I only made minor alterations to the original interface, which
primarily accesses metadata by fetching and setting keys.
this metadata is not used so much during compilation (the compiler keeps its
own data), but is more present so that the runtime is able to figure things
out (especially useful for automatic code generation tasks, managing the
object system, ...). the compiler actually primarily runs and produces 2
forms of output: RPNIL, which goes to the lower compiler stages; and
metadata, which goes into the "metadata repository".
this kind of information would also be likely stored when compiling a
library (stored along with the object modules), and would serve a role
loosely similar to a header file (only, not needing a proper compiler to
parse, more just loading the library into the current program image...).
I am just wondering if people think this is interesting, or at least
"adequate", or if it is really justified to go over to using a more
elaborate structure (namely, a combination of a heirarchy and a relational
database...). actually, I may go and implement such a database system, but
unless needed will probably not use it for compiler/runtime metadata (or,
unless I can figure out a really convinient API for managing operations like
inserts and queries, which IME are generally awkward...).
or such...
comments?...
so, for examples (these are from the external cache, which is a textual dump
of the repository):
here is a struct:
[VFILE_Mount_s]
_=struct
field.0=next
field.1=chain
field.2=iface
field.3=src
field.4=dst
field.5=data
flags=0
[VFILE_Mount_s/chain]
_=field
flags=0
sig=PXVFILE_Mount_s;
[VFILE_Mount_s/data]
_=field
flags=0
sig=Pv
[VFILE_Mount_s/dst]
_=field
flags=0
sig=Pc
[VFILE_Mount_s/iface]
_=field
flags=0
sig=PXVFILE_Mount_Interface_s;
[VFILE_Mount_s/next]
_=field
flags=0
sig=PXVFILE_Mount_s;
[VFILE_Mount_s/src]
_=field
flags=0
sig=Pc
and a few functions:
[VFZIP_CRC32]
_=func
sig=(Pvij)j
[VFZIP_CacheFile]
_=func
sig=(PXVFZIP_Context_s;Pc)v
and a type declaration followed by a struct:
[VFZIP_Context]
_=type
sig=XVFZIP_Context_s;
[VFZIP_Context_s]
_=struct
field.0=fd
field.1=name
field.2=first
field.3=root
field.4=hash
field.5=croot
field.6=cache
field.7=dirty
flags=0
[VFZIP_Context_s/cache]
_=field
flags=0
sig=i
[VFZIP_Context_s/croot]
_=field
flags=0
sig=PXVFZIP_Entry_s;
[VFZIP_Context_s/dirty]
_=field
flags=0
sig=i
[VFZIP_Context_s/fd]
_=field
flags=0
sig=PX_iobuf;
[VFZIP_Context_s/first]
_=field
flags=0
sig=PXVFZIP_Entry_s;
[VFZIP_Context_s/hash]
_=field
flags=0
sig=PXVFZIP_Entry_s;4096
[VFZIP_Context_s/name]
_=field
flags=0
sig=Pc
[VFZIP_Context_s/root]
_=field
flags=0
sig=PXVFZIP_Entry_s;
Return to the
comp.compilers page.
Search the
comp.compilers archives again.