new compiler metadata...

"cr88192" <cr88192@hotmail.com>
Sun, 24 May 2009 13:18:45 -0700

          From comp.compilers

Related articles
new compiler metadata... cr88192@hotmail.com (cr88192) (2009-05-24)
| List of all articles for this month |

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;



Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.