1. Bind Problems (solved?)...
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
2. Re: Bind Problems (solved?)...
Mike Fowler writes:
[a bunch of suggestions about the bind program]
Thanks for the suggestions.
In any redesign of bind, I would seriously consider making
it 2-pass, so it could discard any routines, variables or
constants that aren't used.
Regards,
Rob Craig
Rapid Deployment Software
http://members.aol.com/FilesEu/
3. Re: Bind Problems (solved?)...
Robert Craig wrote:
>Mike Fowler writes:
>[a bunch of suggestions about the bind program]
>
>Thanks for the suggestions.
>In any redesign of bind, I would seriously consider making
>it 2-pass, so it could discard any routines, variables or
>constants that aren't used.
Hmmm. I hate to ask this Rob, but would that be the best way to go?
Sure, condensing code is a good thing and all, but couldn't this
seriously affect code performance/requirements between bound and unbound
code? Even to the extent that the code behaves differently?
An example: I have a program and want to include, in the source code, a
huge sequence (say, for a bitmap or something). I wouldn't actually type
it all out of course, but have a program that inserts it into the source
code.
Now, I'm almost done with the program, and want to test it out on the more
limited of my two systems (trying to insure that as many people can use it
as possible). I comment out the code that actually uses the sequence (which
is stored as a constant), but the constant itself I keep so that the memory
requirements won't differ that much from when I finish.
Now, if when the program were bound that explicit comment were ignored
because it wasn't being "used", the idea won't work. The program would be
eating into virtual memory a lot sooner, which would affect performance;
and heaven help me if I had designed the program to scale itself (more/less
objects, etc.) based on system resources. This sounds like an extrememly
unlikely case, but I've actually thought through the concept while toying
with some ideas...
Rod Jackson
4. Re: Bind Problems (solved?)...
On Mon, 28 Jun 1999, you wrote:
> Robert Craig wrote:
> >Mike Fowler writes:
> >[a bunch of suggestions about the bind program]
> >
> >Thanks for the suggestions.
> >In any redesign of bind, I would seriously consider making
> >it 2-pass, so it could discard any routines, variables or
> >constants that aren't used.
>
> Hmmm. I hate to ask this Rob, but would that be the best way to go?
> Sure, condensing code is a good thing and all, but couldn't this
> seriously affect code performance/requirements between bound and unbound
> code? Even to the extent that the code behaves differently?
<snip>
On the flip side, wouldn't it be nice if bind would discard unused routines
from the Euphoria run-time as well? Then we could get back to writing 5k Hello
World programs, instead of 175k.
Irv
5. Re: Bind Problems (solved?)...
Irv Mullins wrote:
>On Mon, 28 Jun 1999, you wrote:
>> Robert Craig wrote:
>> >Mike Fowler writes:
>> >[a bunch of suggestions about the bind program]
>> >
>> >Thanks for the suggestions.
>> >In any redesign of bind, I would seriously consider making
>> >it 2-pass, so it could discard any routines, variables or
>> >constants that aren't used.
>>
>> Hmmm. I hate to ask this Rob, but would that be the best way to go?
>> Sure, condensing code is a good thing and all, but couldn't this
>> seriously affect code performance/requirements between bound and unbound
>> code? Even to the extent that the code behaves differently?
><snip>
>
>On the flip side, wouldn't it be nice if bind would discard unused routines
>from the Euphoria run-time as well? Then we could get back to writing 5k Hello
>World programs, instead of 175k.
Well, that might solve half of the problem...
The fact that declared code is being ignored isn't obvious from the
source; you'd need the language's documentation. Noting that commented
code won't be compiled, on the other hand, is fairly clear. Not
recognizing that someone else's code could be ignored complicates the
other problems (keep reading.)
It would simply be a Bad Thing to be forced to put something like
myconstant = myconstant
or
dummyvar = myfunction ()
into the source just to make sure that commenting out one small routine
(or even temporarily not making use of the routines in question)
wouldn't result in the exclusion of code. I'd rather be forced to
comment out the code I DIDN'T want in a program than to explicitly
specify "No, I want *this* constant/routine/library to not be ignored."
Yes, I know, including an entire nnnK library just to use a few features
eats into memory and all. But it's logically consistent: if declared, it
exists, as opposed to if used, it exists. That might be hard to determine
with unbound code; it'll kill the few opportunities for dynamic source
code we have (E! and Dynaminc come to mind.) And I don't think programs
using routine_id to choose among several routines, in bound OR unbound
code, will even be possible anymore (object-oriented methods and libraries,
for example.)
I realize my argument against the idea sounds a bit self-serving, but then
again the impact would be somewhat farther reaching than just the few
things I've produced. We're talking about eliminating entire ways of
working in the language here, all for the sake of shrinking (compiled, not
source) code. I would rather see an effort to produce smaller, possibly
more numerous libraries rather than see it all come to that.
Rod Jackson
6. Re: Bind Problems (solved?)...
Irv
Some of that program size is the Causeway extender.
Bernie
