Jacek Czerwinski wrote:
>>> Z języków 'z klamerkami' o jakim-takim przyjęciu na rynku, czy
>>> zainteresowałeś się http://www.lua.org/
>>[ .. ]
>> 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).

jesli masz na mysli lua_Alloc to niestety podstawową wadą tego cuda jest
zwaracanie gołych wskaźników zamiast handli. Efekt: nie moge kompaktować
pamięci. Bez wzgledu na to jaki wymyślę inteligentny allokator - nie
jestem w stanie zarządzać pointerami na pamięć.

> 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).

Wystaczyło by żeby była abstrakcja na pointer.

do góry

Sebastian Biały pisze:
> 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.

Dokładnie. te numery linii, jak się głębiej w to 'wmyśleć' to jeszcze
brak strukturalnych pętli (nie tylko normalnych call), blokowych if'ów.
Oszczędność nie tylko na wykonaniu (mniej więcej o stos, frame na stosie
itd), ale i kompilowaniu (duże AST). Wystarczy skompilować jedną
linijkę, na wykonaniu się objawi czy GOTO 120 w ogóle trafia w
istniejąca linię.

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/
>>> [ .. ]
> >> 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).
>
> jesli masz na mysli lua_Alloc to niestety podstawową wadą tego cuda jest
> zwaracanie gołych wskaźników zamiast handli. Efekt: nie moge kompaktować
> pamięci. Bez wzgledu na to jaki wymyślę inteligentny allokator - nie
> jestem w stanie zarządzać pointerami na pamięć.

pamiętam w ś.p. Palm OS <4 było takie cuś, ni to handler na RAM, ni to
handler na FILE. Nie wiem dlaczego Ci to mówie, bo nie sadze by w tym
była jakś inspiracja.
Pomiędzy zarezerwowaniem a zwolnieniem wiedziało się "gdzie" to jest,
potem mogło być "kompaktowane".


>
> Wystaczyło by żeby była abstrakcja na pointer.

plus manager, plus tablica, plus ... plus jakaś VM, plus system z ochroną ;)

do góry

Sebastian Biały <h...@p...onet.pl> wrote:
> 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..." ;)
... a wlasciwie czemu nie? Jezyk ten jest maly i mozesz go rozbudowac.
A ze skladnai nie ta? Moze wymysl sobie jakas prosta skladnie i napisz maly
translator
na kilka linii kodu w dowolnym jezyku, ktory Ci ta skladnie zamieni na odwrotna
notacje polska Forth'a. Z powazaniem
Adam Przybyla

do góry

Adam Przybyla wrote:
>>e) Możliwie nie zaczyna się na "Fort..." ;)
> ... a wlasciwie czemu nie? Jezyk ten jest maly i mozesz go rozbudowac.
> A ze skladnai nie ta? Moze wymysl sobie jakas prosta skladnie i napisz maly
translator

To już proteza. Założenie: kod jest na karcie SD. Karte wtykasz w dziure
i bangla. Musiałbym ten translator pisać w uC (choć przyznaje,
"skompilowaną" wersję mogę trzymac na SD). Wcześniej zrobie jvm niż tą
protezę ;)

do góry

Sebastian Biały <h...@p...onet.pl> wrote:
> Adam Przybyla wrote:
>>>e) Możliwie nie zaczyna się na "Fort..." ;)
>> ... a wlasciwie czemu nie? Jezyk ten jest maly i mozesz go rozbudowac.
>> A ze skladnai nie ta? Moze wymysl sobie jakas prosta skladnie i napisz maly
translator
>
> To już proteza. Założenie: kod jest na karcie SD. Karte wtykasz w dziure
> i bangla. Musiałbym ten translator pisać w uC (choć przyznaje,
> "skompilowaną" wersję mogę trzymac na SD). Wcześniej zrobie jvm niż tą
> protezę ;)
... hmm, a to: http://home.iae.nl/users/mhx/basic.html ?;-)
Programy w forth'cie zwykle sa male ... Z powazaniem
Adam Przybyla

do góry

On Mon, 19 Apr 2010 15:38:29 +0200, Sebastian Biały
<h...@p...onet.pl> wrote:

>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.

Hmm, może ja mam inną próbkę losową, bo tutaj to ,,Baziki rzondzom'',
ale to raczej inżynierowie (wiekowi) są.

Po drugie - czemu od razu powrót do lat sześdziesiątych - no ja już z
Amigi pamiętam w pełni proceduralno-strukturalnego Basica, tak więc
czy należy się cofać do numeracji linii? Z numeracją linii to
interpreter jest pewno prostszy.

Po trzecie - zmienne, noż ale on ma tylko trzy bazowe typy, numerki,
numerki z przecinkiem i tekst. ,,Humaniści'' mają z tym problem?

Po czwarte, noż cała automatyzacja w Win opiera się na Basicu (VBA for
Applications i takie tam). No i Bill zbudował swoje imperium na tym
języku ;)
>
>> 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 ...
--
Grzegorz Krukowski

do góry

Sebastian Biały pisze:

> 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 ...

Zgubiłem się, w sumie to chcesz to kompilować na docelowej architekturze
czy tylko ładowac i wykonywać?
W sumie i tak "coś" będziesz kablem zapinał żeby aktualizować, i jakiś
protokół (standardowy+swoje dodatki) to bedzie realizować?
Czy swoją konsole do klepania źródel to urzadzenie będzie mieć?

do góry

Grzegorz Krukowski wrote:
> Po drugie - czemu od razu powrót do lat sześdziesiątych - no ja już z
> Amigi pamiętam w pełni proceduralno-strukturalnego Basica

Miała również jedno zero RAMu więcej.

>, tak więc
> czy należy się cofać do numeracji linii? Z numeracją linii to
> interpreter jest pewno prostszy.

Wolałbym nie cofać się w numerację, ale chyba nie ma wyjścia.

> Po trzecie - zmienne, noż ale on ma tylko trzy bazowe typy, numerki,
> numerki z przecinkiem i tekst. ,,Humaniści'' mają z tym problem?

Tumaniści mają. A tumaniści to coś kompletnie innego. Niestety
przewyższają humanistow ilościowo. Muszę więc ich brać pod uwagę.

> Po czwarte, noż cała automatyzacja w Win opiera się na Basicu (VBA for
> Applications i takie tam). No i Bill zbudował swoje imperium na tym
> języku ;)

Bill zbudował swoje imperium na gównianym klonie czegoś w rodzaju CP/M
(w dodatku nawet go nie pisali, tylko kupili). Akurat nie brałbym jego
przykładu jako ogólnego, za dużo tam przypadków. Nijak nie świadczy to o
wyższości BASICa.

do góry

Jacek Czerwinski wrote:
> Zgubiłem się, w sumie to chcesz to kompilować na docelowej architekturze
> czy tylko ładowac i wykonywać?

W kolejności:

a) chce interpretować

b) jak sie nie da to chce kompilować i interpretować na uC

c) jak się nie da to chce dostarczyc skompilowany do uC (ale wtedy w grę
wchodzi tylko JVM na uC).

> W sumie i tak "coś" będziesz kablem zapinał żeby aktualizować, i jakiś
> protokół (standardowy+swoje dodatki) to bedzie realizować?

Karta SD z systemem plików.

> Czy swoją konsole do klepania źródel to urzadzenie będzie mieć?

Nie.

do góry