Bind Problems (solved?)...

new topic     » topic index » view thread      » older message » newer message

Hello all,

WARNING: long message follows...

Regarding the recent discussion on the problem of BIND
not doing as it should and possibly being re-writen, I
have come up with a rough, not very thought-through,
possible solution. It may be the cats whiskers, or is
it just that last coffee speaking?...

Solution:
For this solution to work, BIND must make two passes
through the programme. This may not be ideal, but
binding is only required to be done once, and this
method can potentially create smaller programmes.

PASS ONE: bind runs through the code and collects a
list of all the includes. This could be a fairly quick
pass, and should be easy to code.

PASS TWO: bind places the main programme code in a new
'code heep' file. It then steps through the code
line-by-line, as if running the programme. When a new
procedure or function is defined, bind changes it's
name to a lovely two-letter garbled mess (as it does),
and stores the original name and the new, altered name
of each routine as it goes, eg:

procedure human_understandable_name()
   .. becomes ..
procedure qi()
   .. and bind stores ..
{"human_understandable_name","qi"}

Now, when a routine is called, bind looks up this list
and changes the text as it currently does. It also,
however, changes all literal strings in routine_id
calls, so:

routine_id( "human_understandable_name" )
  .. bind looks up table of changes ..
  .. and it becomes ..
routine_id( "qi" )

This is the -clear_routine and routine_id problem
solved (unless the routine_id's are not literals...)


Also during this pass, bind checks all calls to
routines. If an external (included) routine is called,
bind grabs the called routine code (and any used
constants or varibles) from the include file and
places it into the 'code heep' file. (the code heep is
checked before adding to prevent duplicates.) This
way, if an include file has hundereds of routines in
it, but only uses one or two, then only the routines
used will be included in the bound code. This could
potentially make bound code much smaller, and possibly
even faster??

The last thing to do is to attach ex.exe/exw.exe as
per normal to the code heep, and the programme is
bound.


This solution has, as all do, advantages and
disadvantages.

Advantages:
* no un-used code in bound files
This could be a major bonus if a many large includes
are used only partially.

* routine_id code can be shrouded
No complaints here, I don't imagine.

* It should work (by my theory)
... which no doubt means it wont ...

Disadvantages:
* 2 passes required
Binding is only done once, so the slight extra time
taken for the first pass would be made up for in
smaller bound file-size.

* routine_id's must be literals
Not sure how many people this would affect. I myself
have never written or seen Euphoria code with anything
other than literals used with routine_id().

* bind has to be re-written
Robert says he was expecting to have to re-write bind
in the near future, so this is not too major. And
besides, it's a good project for somebody to write it
in Euphoria...


Is it a good idea, or should I go back to my Kiwi ways
and use number 8 wire to fix the problem?

Happy chewing over it,

Mike Fowler
---
===
Mike Fowler - wildcat_nz at yahoo.com  o__ ---
                                   _,>/'_ ---
"the limitations are limitless"   (_) \(_) ---
 - Beck


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

new topic     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu