<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix">On 2021-02-02 4:50 p.m., Patrick wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:7f5e7b24-1cc4-1cbd-7b35-d132574d005a@spellingbeewinnars.org">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      <div class="moz-cite-prefix">On 2021-01-31 2:57 p.m., Mark H
        wrote:<br>
      </div>
      <blockquote type="cite"
cite="mid:CAA4-YzMgE+zUA0u_--=qangWKWfX87Trc+W8DRPYsgjno3yREg@mail.gmail.com">
        <meta http-equiv="content-type" content="text/html;
          charset=UTF-8">
        <div dir="ltr">Hey guys,
          <div><br>
          </div>
          <div>I have a small project with Jim on an STM32F4
            microcontroller.  It has about 104 KB RAM available to the
            app.  That actually works pretty well, and can navigate its
            UI on a 20x4 character LCD.  I expect to use Jim on other
            MCU projects as well.</div>
          <div><br>
          </div>
          <div>Predictably, it's starting to have serious RAM-cram.  So
            I've been looking at ways to run scripts directly from where
            they reside in flash (effectively ROM).  That way the entire
            application script (plus Jim stdlib) doesn't get copied to
            RAM before it even begins interpreting.  And then each proc
            body copied to more RAM etc. </div>
          <div><br>
          </div>
          <div>So, some open questions:</div>
          <div><br>
          </div>
          <div>1)  Has anybody else tried something similar?  How did
            you approach it and how well did it work?</div>
          <div><br>
          </div>
          <div>2)  I've tried a few approaches so far.  Each of those
            has "almost" run correctly.  The basic problem is that Jim's
            (0.79) hashtables and certain other functions rely on
            null-terminated strings.  They discard or ignore the (in
            most cases) known length of the string.  But those nulls are
            not present when (for example) command or variable name
            tokens point to ROM instead of RAM, because I've shut off
            the strdup that would have made the RAM copy.  The original
            script in ROM has the remainder of the script where the
            interp is expecting the null to be.  I've tracked down and
            fixed those issues in a few important functions, but
            certainly not all.  I've gotten a few lines of script to run
            that way, so it probably can work for the rest.  It looks
            like it might be a long road to complete that approach, and
            would likely introduce bugs wherever i've missed a spot.  I
            have no obvious way to run Jim's test suite on such a small
            host, and no obvious way to make scripts read-only on a PC
            to run the tests there instead.  So...</div>
          <div><br>
          </div>
          <div>3) ...Instead, I'm starting to seriously consider a
            comprehensive solution.  Such as: throughout jim.c, replace
            all char* function parameters with a new structure instead,
            such as "Jim_Text", which carries both the char* and the
            known length.  That would mean basically a wholesale
            paradigm shift from C-style strings to known-length
            strings.  You might say Pascal-style strings, but I wouldn't
            store the length at the front of the string data like Pascal
            does.  That makes it too easy to overlook a piece of code
            that needed the rework, introducing insidious bugs.  The new
            design should pass all existing test suites verbatim.  And
            it should be able to do so on a PC, where the tests are
            available, proving that it's likely to also work on the MCU,
            where tests aren't available.</div>
          <div><br>
          </div>
          <div>4) Is anybody else interested in seeing that approach
            adopted?  There might be other benefits besides running
            scripts from ROM.  One benefit might be a bit faster
            execution, since most strlen() calls or other null-byte
            searches are eliminated.  Currently those are happening
            every time a hash key is computed, and in other hotspots.</div>
          <div><br>
          </div>
          <div>5)  I heard Steve mentioning recent improvements to make
            Jim insensitive to nulls embedded in data.  Anybody care to
            guess how that work interplays with this approach?</div>
          <div><br>
          </div>
          <div>6)  Would anybody else be interested in helping with the
            extensive rework?</div>
          <div><br>
          </div>
          <div>7)  Are there any Tcl TIP's, or Jim open issues, that
            relate to my goal, or to this paradigm shift either?</div>
          <div><br>
          </div>
          <div>Thanks for any clues!</div>
          <div><br>
          </div>
          <div>--</div>
          <div>TheMarkitecht</div>
          <div>
            <div dir="ltr"><span style="font-size:12.8px">"I'm always
                disappointed when a liar's pants don't actually catch on
                fire."</span><br>
            </div>
            <div dir="ltr"><a
                href="https://github.com/TheMarkitecht/slim"
                moz-do-not-send="true">https://github.com/TheMarkitecht/slim</a><span
                style="font-size:12.8px"><br>
              </span></div>
            <div dir="ltr"><br>
            </div>
          </div>
        </div>
        <br>
        <fieldset class="mimeAttachmentHeader"></fieldset>
        <pre class="moz-quote-pre" wrap="">_______________________________________________
jimtcl mailing list
<a class="moz-txt-link-abbreviated" href="mailto:jimtcl@lists.workware.net.au" moz-do-not-send="true">jimtcl@lists.workware.net.au</a>
<a class="moz-txt-link-freetext" href="https://lists.btbrotary.org.au/cgi-bin/mailman/listinfo/jimtcl" moz-do-not-send="true">https://lists.btbrotary.org.au/cgi-bin/mailman/listinfo/jimtcl</a>
</pre>
      </blockquote>
      <p><br>
      </p>
      <p><br>
      </p>
      <p><br>
      </p>
      <p>Hi Mark</p>
      <p>I am sure that Steve knows best with this but just for the
        record, I have wanted to do something like this too. What OS are
        you running? Even if the microcontroller has memory, is there
        anything to stop us from using external memory? Perhaps over SPI
        etc ..</p>
      <p>BTW, if you do go down the Lua road, I was part of eLua and I
        can tell you what I learned from this, just PM me.<br>
      </p>
      <p>-Pat<br>
      </p>
      <p><br>
      </p>
      <p><br>
      </p>
      <p><br>
      </p>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <pre class="moz-quote-pre" wrap="">_______________________________________________
jimtcl mailing list
<a class="moz-txt-link-abbreviated" href="mailto:jimtcl@lists.workware.net.au">jimtcl@lists.workware.net.au</a>
<a class="moz-txt-link-freetext" href="https://lists.btbrotary.org.au/cgi-bin/mailman/listinfo/jimtcl">https://lists.btbrotary.org.au/cgi-bin/mailman/listinfo/jimtcl</a>
</pre>
    </blockquote>
    <p>I just looked up the STM32F4 and it does not run RetroBSD. I am
      not sure if you can squeeze Bertos or Contiki on it but it is
      smaller than I thought.</p>
    <p>I asked about running jim on baremetal once and there is a thread
      about this if you want me to forward old emails. It does not sound
      possible as so much of jim is tied to the OS.</p>
    <p>Sorry for the noise everyone<br>
    </p>
  </body>
</html>