Hi Magnus,
[snip]
>Hurray! Now, what warts (except non-support for the three features above)
>where you thinking of? Would you care to spell (spit???) it out?
Several warts:
1. Performance. A few people have complained at the rather pathetic
speed at which medium complex circuits netlist. gnetlist has survived
this only because machines have gotten faster. There is a lot
that can be done here. (btw, we are talking about the C part. The
scheme part isn't the problem).
2. Fragile code. Even though gnetlist works reasonably well, I am
not thrilled about changing certain pieces of it. I do have some
regression tests for gnetlist, but not nearly enough to allow me to
sleep at night.
3. Implementation details. There are a few parts of the code that
are questionable and I would like to fix them, but see #2.
4. Not nearly extensively and transparent as I would like. Some more
radical things (like proper backannotation) are hard without exposing
more internals. This needs to be done carefully.
Keep in mind, a rewrite of gnetlist is still all in my mind and dreams,
so don't get too excited. :)
[snip]
>What I would consider as an alternative strategy is to phase out guile as the
>basis for gnetlist backends (and please note, I am *only* speaking about
>gnetlist backends) and do them in C instead. What is good with the gnetlist
Hmmm. I don't know if C is really suitable for this. Primarily
because it is so dang low level. I doubt many backends would have gotten
written, if the only interface was in C. The last thing people want to
worry about is memory allocation, structures, pointers, etc...
-Ales
