[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Guile Binary Format 0.1

From: Keisuke Nishida
Subject: Guile Binary Format 0.1
Date: Mon, 05 Feb 2001 15:24:08 -0500
User-agent: Wanderlust/2.4.0 (Rio) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) Emacs/21.0.96 (i686-pc-linux-gnu) MULE/5.0 (SAKAKI)

At Sat, 03 Feb 2001 11:56:27 -0500,
Keisuke Nishida wrote:
> foo_dump (SCM obj, SCM dstate)
> {
>   struct foo *p = FOO_DATA (obj);
>   scm_dump_word (p->x, dstate);
>   scm_dump_word (p->y, dstate);
>   scm_dump_object (p->bar, dstate);
>   scm_dump_object (p->baz, dstate);
> }

I have implemented this version.  Now objects are stored using a stack.
When scm_dump_object is called and the object has not been stored yet,
it is pushed into a stack and the rest of tasks are automatically
scheduled.  So a smob writer don't need to think about it.

An undump function looks like this:

  foo_undump (SCM dstate)
    struct foo *p = scm_must_malloc (sizeof (struct foo), "foo_undump");
    p->x = scm_undump_word (dstate);
    p->y = scm_undump_word (dstate);
    scm_undump_object (&p->bar, dstate);
    scm_undump_object (&p->baz, dstate);
    SCM_RETURN_NEWSMOB (scm_tc16_foo, p);

It's not symmetry, but probably this is easier to use.  If you want
to dump/undump a cell object, you should write it as follows:

  foo_dump (SCM obj, SCM dstate)
    scm_dump_cell_object (SCM_CELL_OBJECT_1 (obj), dstate);

  foo_updump (SCM dstate)
    SCM smob;
    SCM_NEWSMOB (scm_tc16_foo, smob, 0);
    scm_undump_cell_object (smob, 1, dstate);
    return smob;

I have modified the binary format as well.  As Dirk and Michael
have suggested, I store objects with their tc tags in the order
a developer specified.  There is no longer a meta section.

  Format #1: [\?GBF][-0.1][immediate]
  Format #2: [\?GBF][-0.1][# of objs][tc][data][tc][data]...

The code became much simpler and now I think this is better.
I always make a bad decision at the beginning..  I really need
more programming experience, sigh.

There are some potential places of improvement, though.  Since
objects are dumped from the beginning, lots of reference linking
can be delayed during undump.  For example, a list (foo bar) is
stored as follows:

  [\?GBF ][-0.1][   4]
  [cons  ][  #1][  #2]
  [symbol][foo ]
  [cons  ][  #3][  ()]
  [symbol][bar ]

When the first cons is undumped, object #1 and #2 are not yet
created, so linking are delayed and scheduled using malloc.
This may produce a number of of malloc calls.  On the other
hand, if I store them in the reverse order as follows,

  [\?GBF ][-0.1][   4]
  [symbol][bar ]
  [cons  ][  #0][  ()]
  [symbol][foo ]
  [cons  ][  #2][  #1]

no malloc is needed.  In order to do this while keeping the
current simple dump interface, a little trick is needed.
I'll implement it some time if it seems to be significant.

It is possible to do more trivial optimization, but probably
I shouldn't do that now.  So I'm going to keep this format.
If someone want to add more object support, please do so.

I haven't fixed the smob tc problem yet.  Only file ports
with mmap are supported.  Only one object can be read.
No documentation yet.  I'll add them some time later.

I appreciate any comments.

Keisuke Nishida

reply via email to

[Prev in Thread] Current Thread [Next in Thread]