Witam.

Sprawa jest nie do końca związana z konkretnym językiem, więc pozwalam
sobie tutaj zasięgnąc rady.

Mam CPU z 64kB RAM i 128kB ROM w którym około 80kB jest w tej chwili
wolne. Jest to ARM.

Ze względu na specyfikę zastosowania chciałbym umieścić wewnatrz jakiś
wygodny język programowania embedded ktory w szczególności:

a) nie wymaga kompilacji w sposob jawny - dostarczam do CPU kod źrodlowy.

b) blizej mu do językow skryptowych niż silnie typowanych

c) ma skladnię zbliżoną do C/C++/Java/Javascript - "klamrowy" lub
podobny w sensie wyglądu kodu

d) jesli BASIC to jakiś normalny (przykaład nienormalnego - TigerBasic).

e) Możliwie nie zaczyna się na "Fort..." ;)

f) nie uzywa malloc/free (nie ma tam MMU), _idealnie_ jesli posiada
kompaktujący GC.

g) jesli to ja dostarczam abstrakcję pamięci, to można sie pokusić o coś
w rodzaju swapa tylko dla niego (w systemie istnieje dysk hdd).

h) prędkośc bez znaczenia (w granicach rozsądku).

Niestety z punktu widzenia mojego punkt f) jest dośc istotny,
fragmentacja pamieci jest katastrofą dla mojego CPU, a wsadzenie czegoś
z MMU oznacza zasadniczy skok kosztów.

Teraz pytanie, czy ktoś ma pomysł co wklepać w google? Najbardziej
chciałbym JavaScript, ale wszystkie jego engine które oglądałem
zakładają że istnieje malloc/free/new/delete i używają tego bardzo
rozrzutnie (nie jest też możliwe zrobienie kompaktującego GC).

PS. Pytalem kiedyś o coś podobnego, ale teraz mam _wypasioną_ pamięć
64kB więc zmieniają się warunki ;)

do góry

Welcome to the desert of the real, Sebastian Biały...
> Witam.
>
> Sprawa jest nie do końca związana z konkretnym językiem, więc pozwalam
> sobie tutaj zasięgnąc rady.
>
> Mam CPU z 64kB RAM i 128kB ROM w którym około 80kB jest w tej chwili
> wolne. Jest to ARM.
> Ze względu na specyfikę zastosowania chciałbym umieścić wewnatrz jakiś
> wygodny język programowania embedded ktory w szczególności:
>
Whoa, dejavu...
Jakiś czas temu prowadziłem podobne poszukiwania.
W rezultacie na placu boju pozostały z dwie maszyny wirtualne (NVM i nanoVM),
basic jeszcze z czasów 8052 (jesli ktoś ma dość zapału na konwersję, to niech
da znać jak mu poszło ;) oraz uBasic < http://www.sics.se/~adam/ubasic/ >
Mozesz też rzucić okiem na pakiety : nesla, ee, probasic czy picoc.

Sławek
--
________
_/ __/ __/ Ooooo, jesst mały problem. -- Sid
\__ \__ \___________________________________________________
____________
/___/___/ Sławomir Szczyrba steev/AT/hot\dot\pl

do góry

Sławomir Szczyrba pisze:
> Welcome to the desert of the real, Sebastian Biały...
>> Witam.
>>
>> Sprawa jest nie do końca związana z konkretnym językiem, więc pozwalam
>> sobie tutaj zasięgnąc rady.
>>
>> Mam CPU z 64kB RAM i 128kB ROM w którym około 80kB jest w tej chwili
>> wolne. Jest to ARM.
>> Ze względu na specyfikę zastosowania chciałbym umieścić wewnatrz jakiś
>> wygodny język programowania embedded ktory w szczególności:
>>
> Whoa, dejavu...
> Jakiś czas temu prowadziłem podobne poszukiwania.
> W rezultacie na placu boju pozostały z dwie maszyny wirtualne (NVM i nanoVM),
> basic jeszcze z czasów 8052

Z kolei moja myśl idąc przez interpretery na tak slaby sprzet,
zauwazyla, że jedyny sposób na ograniczone potzreby RAM ze wzgledu na
kompilacje i ładowanie, to jezyk niestrukturalny (w praktyce Basic z
numerami linii lub Forth - jednostką kompilacji jest pojedyncza linia
lub podobny byt). Posiadanie bloków, instrukcji strukturalnych (klamerek
z C) wymusza pojawienie się drzewa programu (AST) o rozmiarze
odwzorowującym potencjalnie cały program.

Maszyna wirtualna to co innego jeśli chodzi o spojrzenie przez RAM.

Co nie zmienia faktu że historycznie na 64kB RAM bywały już kompilatory
(zwykle jednak z nakładkami lub etapami), może jakies szkolne w jednym
"kawałku"

do góry

Sławomir Szczyrba wrote:
> W rezultacie na placu boju pozostały z dwie maszyny wirtualne (NVM i nanoVM),

maszyne wirtualną Javy z kompaktacją pamięci sobie wlasnie skrobie na
boku, ale chodzi mi raczej o trywialny język typu procedura, pętla,
zmienna ktory jest wygodny w zapisie dla tumanisty który to będzie misla
czasem z lekka poprawić.

> Mozesz też rzucić okiem na pakiety : nesla, ee, probasic czy picoc.

Dzieki. Acz basica staram się uzyć w ostateczności.

do góry

Jacek Czerwinski wrote:
> Z kolei moja myśl idąc przez interpretery na tak slaby sprzet,

50MHz i słaby sprzęt :P

> zauwazyla, że jedyny sposób na ograniczone potzreby RAM ze wzgledu na
> kompilacje i ładowanie, to jezyk niestrukturalny (w praktyce Basic z
> numerami linii lub Forth - jednostką kompilacji jest pojedyncza linia
> lub podobny byt).

Słabo znam się na interpretatortach, ale zanim zaczne zastanawiać się
nad JVM/Dalvik i pośrednią kompilacją (co jest wyjsciem chyba dość
rozsądnym na tyle RAMu) wole wybadac, bo może akurat nie muszę męczyć
się z Javą jeśli jest jakiś gotowieć w rodzaju ładnego embedded BASICa
na "już".

> Co nie zmienia faktu że historycznie na 64kB RAM bywały już kompilatory
> (zwykle jednak z nakładkami lub etapami), może jakies szkolne w jednym
> "kawałku"

Nie spodziewam się że ktoś zrobi szybki, wydajny i mały interpretter
JavaScriptu mieszczący się w 64kB RAM. Choć na nim zależało by mi
najbardziej, nawet wycinając funkcjonalność :)

do góry

Sebastian Biały pisze:
> Jacek Czerwinski wrote:
>> Z kolei moja myśl idąc przez interpretery na tak slaby sprzet,
>

> Nie spodziewam się że ktoś zrobi szybki, wydajny i mały interpretter
> JavaScriptu mieszczący się w 64kB RAM. Choć na nim zależało by mi
> najbardziej, nawet wycinając funkcjonalność :)

Z języków 'z klamerkami' o jakim-takim przyjęciu na rynku, czy
zainteresowałeś się http://www.lua.org/ ręcznie wykonany (podawany w
rankingach jako szybki), o nieprzesadnym zuzyciu RAM (co nie znaczy, że
obiecuję zmieszczenie się w Twoich kryteriach), bardzo dużo
funkcjonalności wyniesione do opcjonalnych modułów. Nawet 'podstawowy
typ liczbowy' da się podmieniać.

Wbudowywałem kiedyś do aplikacji C++, więc jest znacznie mniejszy od
SpiderMonkey-a.

do góry

Jacek Czerwinski wrote:
> Z języków 'z klamerkami' o jakim-takim przyjęciu na rynku, czy
> zainteresowałeś się http://www.lua.org/

Używałem go już kilka razy w róznych okoliocznościach i nie przekonuje
mnie składnią, choć jest lepiej niz w BASICu oczywiście. Niestety będą
kłopoty z pamięcią, o ile pamiętam engine lua robi malloc/free podczas
pracy co w moim wypadku oznacza szatkowanie skromnej pamięci.

do góry

Sebastian Biały pisze:
> Jacek Czerwinski wrote:
>> Z języków 'z klamerkami' o jakim-takim przyjęciu na rynku, czy
>> zainteresowałeś się http://www.lua.org/
>
> Używałem go już kilka razy w róznych okoliocznościach i nie przekonuje
> mnie składnią, choć jest lepiej niz w BASICu oczywiście. Niestety będą
> kłopoty z pamięcią, o ile pamiętam engine lua robi malloc/free podczas
> pracy co w moim wypadku oznacza szatkowanie skromnej pamięci.
a) przez wrapper(pojedynczy interfejs) więc jest na to jakiś wpływ
(sub-alokator, te wzorce).
b) wg mojej intuicji (nie mam twardych dowodów) chyba nie da się
intepretera zrobić do języka strukturalnego (tzw nie basic tylko z
numerami linii typu ZxSpectrum, Commodore lub z innej strony Forth) bez
alokowania (być może podmienionym alokatorem). Nos mówi mi, że to
związane. Jednak np radykalnie stosowa koncepcja Forth'a ułatwia
nieszatkowanie pamięci. Nigdy nie przeprowadziłem z kims dyskusji, czy
taki wymyślony związek to tylko moja chora wyobraźnia, czy realia tzw
'życia'.

do góry

On Sat, 17 Apr 2010 23:36:23 +0200, Sebastian Biały
<h...@p...onet.pl> wrote:

>Sławomir Szczyrba wrote:
>> W rezultacie na placu boju pozostały z dwie maszyny wirtualne (NVM i nanoVM),
>
>maszyne wirtualną Javy z kompaktacją pamięci sobie wlasnie skrobie na
>boku, ale chodzi mi raczej o trywialny język typu procedura, pętla,
>zmienna ktory jest wygodny w zapisie dla tumanisty który to będzie misla
>czasem z lekka poprawić.
>
>> Mozesz też rzucić okiem na pakiety : nesla, ee, probasic czy picoc.
>
>Dzieki. Acz basica staram się uzyć w ostateczności.

Ależ Basic był w tym celu stworzony. To że Tobie to nie pasuje to
jedno ;) wczuj się w użytkownika, Basicowate są proste jak tylko mogą
być. Na dodatek dla Basica masz bardzo dużą bazę tutoriali i na
podstawowym poziomie są bardzo przenośne.
--
Grzegorz Krukowski

do góry

Grzegorz Krukowski wrote:
>>Dzieki. Acz basica staram się uzyć w ostateczności.
> Ależ Basic był w tym celu stworzony. To że Tobie to nie pasuje to
> jedno ;) wczuj się w użytkownika, Basicowate są proste jak tylko mogą
> być.

Nie. BASIC w implementacjach embedded zazwyczaj nie ma procedur ( a
tylko głupie bezparametrowe gosub), pojecia zmiennych lokalnych, trzeba
pamiętać o różnicach miedzy zmiennymi nie string a string (to śmieszne
$), brzydką składnię z numeracją linii itd. Program w javaScripcie
wyglada znacznie bardziej przejrzyście niż w BASICu. Przetestowalem to
na humanistach, tumanistach i innych nie inżynierach i wnioski są
właśnie takie. Łatwiej tumaniscie poprawić coś w JavaScricie niż w BASICu.

> Na dodatek dla Basica masz bardzo dużą bazę tutoriali i na
> podstawowym poziomie są bardzo przenośne.

E tam, BASIC ma chyba najwięcej niezgodnych z sobą implementacji. Nie
wiem czy przebija to jakikolwiek inny język na świecie, na pewno na
kilkanascie jakie miałem w ręku różnice były kolosalne. Po ostanich
przejściach z TigerBasic-em wolałbym oszczędzić userowi całego stada
problemów jakie napotkałem. Dlaetgo basic tak, ale to ostatczenośc,
prędzej napiszę to JVM ...

do góry