Shrinking V

[burnsauce]

I have 2 ideas for shrinking the size of V, both of which presume that the names of the internal words are unimportant and disposable. If this assumption is not in keeping with project goals, I'll abandon the effort.

1. Perform source-file translation of v.fs (at build time) to shrink the size of dictionary text entries.
2. Use :noname to remove all internal words from the dictionary

Which approach should I take? 1 is easy but nasty, polluting the dictionary with meaningless words, without very much space saving. 2 would save a lot more space and keep the dictionary clean, but v.fs will become more complex.

[gitjeff2]

There are a few other projects that have expressed interest in porting V to other Forth implementations on other CPU architectures. The CollapseOS crowd comes to mind. They're starting with their own Z80 Forth and going 8/16-bit cross platform from there.

Hypothetically, could V be shrunk in such a way as to increase its portability across architectures? I haven't had time to dig into it myself.

[burnsauce]

The 2 option would not be portable beyond 6502 and the threading model used in durexforth, as it would involve directly assembling JSR instructions.

[jkotlinski]

One idea that crossed my mind would be having some other dictionary structure, that allows for temporary dictionaries that can be discarded when no longer needed. Of course, it would be some work setting that up.

[burnsauce]

You mean like this?

latest @ $a000 !
here $a002 !
$a004 to here
: splice $a000 @ $a002 @ ! ;
\ build some compile-time helpers
$a002 @ to here

\ write code that uses helpers OUTSIDE of the compile state
splice

(I've actually given this a lot of thought including tail compiling after pushya and other such nonsense but this solution was the cleanest)

I've done :noname swapping on two words as a proof-of concept, and the above code supports that, but the implementation is simple and the substitution is currently ugly, with noname word calls looking like [ 'e' vf ] for editpos for instance. I am writing one that uses WORD instead, but don't know if I'll be able to strip the explicit brackets.

That said, a long run of internal words could fit inside brackets, so maybe it won't look too bad.

[burnsauce]

Ah, I have the full, clean solution! Using the above to hide compile-time words, I added the words (without looking at the standard, no doubt non-compliant) DEFER and IS where DEFER spits out a JSR, of the contents of the data field.

Nonaming can now be completed entirely at word definition, no further source changes required. The result is a clean dictionary with nothing but a smaller V, where the source file remains readable. If this is an acceptable strategy, I'll do the legwork then send in a PR.

Example:

\ Inside the hidden dictionary
: defer create 0 , does> @ jsr, ;
: is parse-name find-name if 5 + ! else 2drop then ;

defer editpos immediate

\ back in the main dictionary
:noname curlinestart @ curx @ + ; is editpos

This exact solution with no further source changes results in the expected 10-byte savings and a functional V.

[jkotlinski]

What I had in mind was to put the dictionary in its own memory space, so that it has it's own HERE and LATEST pointers. This means word headers would be completely separate from code and data.

Doing this has some advantages

• when doing "turnkey" applications, the dictionary can be stripped away entirely for a smaller binary
• after compiling V, all word headers can be discarded, except the ones that are necessary for using the application

[burnsauce]

To the meat of this issue: should I continue with a custom solution for V? It's a major percentage of the "internal" words in the binary distribution. There are ~850 bytes to be gained there, but only a handful before ---editor--- that are not required to be interpreted.

I like the broad approach of a separate dictionary, but it's a long row to hoe compared to hacking V, IMO. Then again, I didn't architect durexforth ;)

[jkotlinski]

It depends a bit what your motivation is. If you need those bytes urgently to do something, by all means go ahead. The problem of word headers wasting space is not unique to the editor though, its equally a problem to the other modules. That’s why I think it might be better to try to solve the problem on a higher level.

On Mon, 12 Oct 2020 at 20:27, Poindexter Frink notifications@github.com wrote:

To the meat of this issue: should I continue with a custom solution for V? It's a major percentage of the "internal" words in the binary distribution. There are ~850 bytes to be gained there, but only a handful before ---editor--- that are not required to be interpreted.

I like the broad approach of a separate dictionary, but it's a long row to hoe compared to hacking V, IMO. Then again, I didn't architect durexforth ;)

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/jkotlinski/durexforth/issues/268#issuecomment-707278669, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAY34O6UJ2K57VLRXA4HCWLSKNDC7ANCNFSM4SKPN5MQ .

[burnsauce]

I was looking to push a shrink patch upstream so that I could work on expanding the editor without bumping the cart limit. If you're going to rework the wordlist for the next release then shrinking V exclusively would never see the light of day, I suppose.

I'll just work on expanding the editor for now and submit PRs once the cart can support it. Closing this issue.