Saturday, January 17, 2015

ElWhip Diet

I have been working on getting my ElWhip web server running in 128K, but I'm not there yet. It is crashing on a 128K Mini vMac right after it negotiates the IP addresses. So close!
The main cause is PPP, which takes up about half of the memory. I tried replacing PPP with SLIP today, but I can't get slattach (SLIP server) to work on Mac OS X 10.4, and it isn't included in newer versions of OSX. So, it's not a good solution. Click for the gory details...

Here is the error I get with slattach:
ioctl(TIOCSETD): Operation not supported by device
But it says that for all of my devices. If anyone has a solution, I would be glad to hear it.

Here is a dump that shows the code sizes:
DumpCode -n ElWhip 1 'vers' [43] 128 'ics8' [256] 128 'ics#' [64] 128 'icl8' [1024] 130 'MENU' [72] 129 'MENU' [29] 128 'MENU' [41] 128 'MBAR' [8] 0 'LWIP' Owner resource [1] 128 'ICN#' [256] 128 'FREF' [7] 129 'DITL' [78] 128 'DITL' [156] 9 'CODE' SACONSOLE [1800] 8 'CODE' SADEV [2258] 7 'CODE' INTENV [2386] 6 'CODE' %A5Init [10458] 5 'CODE' STDIO [4806] 4 'CODE' LWTCP [14644] #3 'CODE' LWPPP [23846] 2 'CODE' Initialize [132] 1 'CODE' Main [9532] 0 'CODE' [1392] 128 'BNDL' [28] 129 'ALRT' [14] 128 'ALRT' [14]
Compare with SLIP:
#3 'CODE' LWPPP [2090]
at about 1/10th the size. Since SLIP isn't a legitimate option these days, I did my best to slim down the code by:

  • turning off pretty much all logging
  • switched from RAM serial driver to ROM serial driver
  • commented out some extraneous logging in PPP

Unfortunately, I think the only way to beat this is to put the different parts of ppp in different segments. Once the link is established, I will unload the LCP and IPCP portions of PPP which we should be done with.

5 comments:

  1. Maybe an interesting code size comparison - ARM gives some size estimates for their PPP implementation using THUMB instructions in their "Porting PPP Programmer's Guide" (http://infocenter.arm.com/help/topic/com.arm.doc.dui0143b/DUI0143B.pdf).

    On page 1-9, ARM gives the code size in bytes for a minimal PPP implementation (I have no idea what they used as a code base) including IPCP and LCP with all options except NB_CONNECT disabled as 20348 bytes of ROM and 684 bytes of RAM. Pretty close to your numbers on the 68k, I think.

    ReplyDelete
  2. One more idea - the PPP code might actually be a good target for a superoptimizer (http://en.wikipedia.org/wiki/Superoptimization). The first one was used in Massalin's PhD thesis on the Synthesis OS to reduce the code size on the custom-built 68020 machine [1]. That might be an interesting challenge - do you consider publishing the ElWhip source some day? (though the superoptimizer works on assembler code, so the CODE resource should suffice ;-)).

    [1] Henry Massalin. 1987. Superoptimizer: a look at the smallest program. In Proceedings of the second international conference on Architectual support for programming languages and operating systems (ASPLOS II), Randy Katz (Ed.). IEEE Computer Society Press, Los Alamitos, CA, USA, 122-126.

    ReplyDelete
  3. It might also be worth to check if the PPP code from EthnerNut results in a smaller binary: http://sourceforge.net/p/ethernut/code/HEAD/tree/trunk/nut/net/

    ReplyDelete
  4. Oh my, once you start doing some research... this thread (http://www.embeddedrelated.com/groups/lpc2000/show/11148.php) mentions that the Contiki PPP code is a stripped down version of the lwIP PPP implementation. I didn't try to compile it, but this might be another alternative worth investigating:

    https://github.com/adamdunkels/contiki-1.x/tree/master/contiki

    ReplyDelete
  5. Thanks for all of this information! I will make the mac code available to the lwip people, but I am still working on it to get it done by the end of the month.
    Last I checked, Contiki only had SLIP. I will look into it...

    ReplyDelete