Quali sono i linguaggi interattivi disponibili che vengono eseguiti in una memoria minuscola?

Sto cercando linguaggi di programmazione generica

  • avere un prompt interattivo (live coding)
  • funziona in 32 KB di RAM da solo o 8 KB quando il compilatore è ospitato su una macchina separata
  • eseguire su un microcontrollore con un minimo di 8-32 KB di RAM totale (senza MMU).

Di seguito è la mia lista finora, cosa mi manca?

  • Python : PyMite VM ha bisogno di 64K flash, 8K di RAM. Mira a LPC, SAM7 e ATmegas con 8K o più. Ospitato.
  • Lua : le domande frequenti su eLua consigliano flash 256K, 64 KB di RAM.
  • FORTH : amforth ha bisogno di 8K flash, 150 byte di RAM, 30 byte EEPROM su un ATmega.
  • Schema : armpit Scheme L’objective più piccolo è LPC2103 con 32K Flash, 4K SRAM.
  • C : Interactive C funziona su 68HC11 senza flash e SRAM 32K. Ospitato.
  • C : picoc un sistema C interattivo, cross-compiling, open source. Quando compilato per AVR, richiede un flash da 63 K, 8 K RAM. La RAM potrebbe essere ridotta con lo sforzo di mantenere le tabelle in flash.
  • C ++ : AngelScript è un linguaggio di scripting open source, basato sul codice byte, C / C ++ con semplici chiamate native.
  • Tcl : TinyTCL gira su DOS, binario 60K. Sembra facile da portare.
  • BASIC : TinyBasic : inizializza con un heap di 64 KB, potrebbe essere regolabile.
  • blesità
  • PostScript : (Non ho ancora trovato un’implementazione FOSS per la memoria insufficiente)
  • Shell : bitlash : una shell di comando intertriggers per Arduino (ATmega). Vedi anche AVRSH .

Esistono diverse versioni di Tcl per la programmazione integrata:

http://wiki.tcl.tk/1363

Un runtime homebrew di Forth può essere implementato in pochissima memoria. Conosco qualcuno che ne ha fatto uno su un Cosmac negli anni ’70. Il runtime di base era di soli 30 byte.

Ho sentito che CHIP-8, XPL0, PicoC e Objective Caml sono stati trasferiti su calcolatori grafici. L’articolo “Lego Mindstorms” di Wikipedia elenca un sacco di linguaggi di programmazione che presumibilmente funzionano sulla piattaforma Lego RCX o Lego NXT. Qualcuno di loro ha i suoi criteri “live coding”?

Potresti voler controllare gli altri microcontrollori Forth nella wiki di Forth. Elenca almeno 4 Forths per l’Atmel AVR: amforth (che già citi), PFAVR, avrforth e ByteForth.
(I link a tali interpreti, così come questa domanda StackOverflow, sono inclusi nel wikibook ” Embedded Systems “).

Vorrei raccomandare LUA (o eLUA http://www.eluaproject.net/ ). Ho “portato” LUA su un Cortex-M3 qualche tempo fa. Dall’alto della mia testa aveva una dimensione del flash di 60 ~ 100KB e avevo bisogno di circa 20KB di RAM per funzionare. Mi sono spogliato fino all’essenziale, ma a seconda dell’applicazione, potrebbe essere sufficiente. C’è ancora spazio per l’ottimizzazione, in particolare per quanto riguarda i requisiti di RAM, ma dubito che sia ansible farlo funzionare comodamente in 8 KB.

Wren soddisfa i tuoi criteri: per impostazione predefinita è configurato per utilizzare solo 4k di RAM. AFAIK non ha visto alcun uso effettivo, dal momento che il ragazzo che ho scritto per decidere ha deciso che non aveva bisogno di un interprete che si dirigesse interamente sul sistema di destinazione dopotutto.

La lingua è influenzata più chiaramente da ML e Forth.

Hai considerato una porta in C di Tiny Basic ? O forse riscrivendo la p-machine UCSD Pascal nella tua architettura da Z-80?

Seriamente, però, JavaScript sarebbe un buon linguaggio di scripting incorporato, ma non ho idea di quali siano i requisiti minimi di memoria per VM + GC, né quanto sia difficile rimuovere le dipendenze del SO. Ho giocato con NJS qualche tempo fa, che potrebbe adattarsi alle tue esigenze. Questo è interessante in quanto il compilatore è scritto in JavaScript (self hosting).

Puoi dare un’occhiata a AvrCo Multitasking Pascal molto potente per AVR. Puoi provarlo su http://www.e-lab.de . La versione MEGA8 / 88 è gratuita. Ci sono un sacco di driver e simulatore con debugger JTAG e belle visualizzazioni live o simulate di tutti i dispositivi standard (LCDCHAR, LCDGRAPH, 7SEG, 14SEG, LEDDOT, KEYBOARD, RC5, SERVO, STEPPER …).

Ti manca EmbedVM, homepage qui , svn repo qui . Ricordati di controllare entrambi i video [ 1 , 2 ] sulla prima pagina;)

Dalla homepage:

EmbedVM è una piccola macchina virtuale incorporabile per microcontrollori con un frontend in linguaggio C simile. È stato testato con microcontrollori GCC e AVR. Ma poiché la macchina virtuale è piuttosto semplice, dovrebbe essere facile portarla su altre architetture.

La VM simula una CPU a 16 bit che può accedere a 64kB di memoria. Può funzionare solo su valori a 16 bit e array di valori a 16 bit e 8 bit. Non c’è supporto per strutture dati complesse (struct, objects, ecc.). Una funzione può avere un massimo di 32 variabili locali e 32 argomenti.

Oltre alla memoria per la VM, una piccola struttura che contiene lo stato della VM e la ragionevole quantità di memoria che le funzioni di EmbedVM hanno bisogno sullo stack, non ci sono requisiti di memoria aggiuntivi per la VM. Soprattutto la VM non dipende da alcuna gestione della memoria dymaic.

EmbedVM è ottimizzato per dimensioni e semplicità, non per velocità di esecuzione. La VM stessa occupa circa 3kB di memoria di programma su un microcontrollore AVR. Su un AVR ATmega168 in esecuzione a 16 MHz, la VM può eseguire circa 75 istruzioni VM per millisecondo.

Tutti gli accessi alla memoria effettuati dalla VM sono configurati utilizzando le funzioni di callback dell’utente. Quindi è ansible avere parte o tutta la memoria VM su dispositivi di memoria esterni, memoria flash, ecc. O funzioni hardware “mappa di memoria” sulla VM.

Il compilatore è uno strumento della riga di comando UNIX / Linux che legge in un file * .evm e genera bytecode in vari formati (file binario, hex hex, inizializzatori di array C e un formato di output di debug speciale). Genera anche un file di simboli che può essere utilizzato per accedere ai dati nella memoria della macchina virtuale dall’applicazione host.

Il linguaggio simile a C assomiglia a questo: http://svn.clifford.at/embedvm/trunk/examples/numberquizz/vmcode.evm

Vorrei raccomandare MY-BASIC , funziona con almeno 8 KB di RAM e facile da portare.

Suggerirei di usare Python. Ma ora l’unico problema è il sovraccarico della memoria, giusto? Quindi ho una grande idea per le persone che potrebbero essere bloccate in questo problema in seguito.

Per prima cosa, scrivi un interprete bf (o ottieni semplicemente il codice sorgente da qualche parte). L’interprete sarà davvero piccolo. Anche bf è un linguaggio completo di Turing. Ora devi scrivere il tuo codice in python e poi trasferirlo su bf usando bfpy ( https://github.com/felko/bfpy/blob/master/README.md ). Ti ho dato la soluzione con il minimo sovraccarico e sono abbastanza sicuro che un interprete bf rimarrà facilmente sotto i 10KB di RAM.

Hai considerato semplicemente l’utilizzo di /bin/sh fornito da busybox ? O dei più piccoli linguaggi di scripting che raccomandano?

Ho usato nel mio precedente lavoro busybox su un BlackFin.

abbiamo compilato perl + php per questo, dopo aver cambiato s / fork / vfork / g ha funzionato abbastanza bene … più o meno. Non avere una MMU non è una buona idea. La frammentazione della memoria ucciderà il server abbastanza facilmente. Tutto ciò che ho fatto è stato:

 for i in `seq 1 100`; do wget http://black-fin-ip/test.php; done 

È morto mentre stavo camminando verso il mio capo e dicendogli che il server morirà in produzione 🙂

Prolog – http://www.gprolog.org/

Secondo una ricerca su google “prolog small”, la dimensione dell’eseguibile può essere ridotta, evitando di colbind i predicati incorporati.

C’è anche JavaScript, tramite Espruino .

Questo è costruito specificamente per i microcontrollori e ci sono build per diversi chip (principalmente STM32) che si adattano a un sistema completo in un minimo di 8kB di RAM.