uC z =?ISO-8859-2?Q?j=EAzykiem_skryptowym?=



Masz problem? Zapytaj na forum elektroda.pl

Poprzedni Następny
Wiadomość
Spis treści
From: Sebastian Bialy <heby_at_nospam_poczta.onet.pl>
Subject: uC z =?ISO-8859-2?Q?j=EAzykiem_skryptowym?=
Date: Thu, 20 Jan 2005 09:46:34 +0100


Witam!

Jest sobie uC. W uC siedzi program, który jest niezmienny. Niestety
zewnątrzne zastosowanie uC jest nieco różne: konkretnie ma on się
zajmowac podejmowaniem decyzji i decyzje te mogą się zmieniać w
zalezności od konkretnego egzemplarza.

Chciałbym zrobić wobec tego coś takiego: ponieważ prędkość nie jest
krytyczna chcę zaszyć w pamięci Flash uC zestaw procedur, a w
zewnątrznym eepromie i2c coś w rodzaju skryptu, który z nich korzysta.
uC emulowałby taki wirtualny assembler wykonując krok po kroku
zewnątrzny program.

#1:
Czy istnieje jakiś taki gotowy jezyk ? Nie potrzebuje funkcjonalności
Byterun Java, mam na myśli coś znacznie prostszego.

#2:
Jesli nie istnieje, to będe musiał wymysleć. Wykombinowałem sobie to
tak, że wirtualna maszyna może mieć jeden akumulator i zestaw instrukcji
działających na adresach bezwzględnych. Na przykład "dodaj do accu
wartość z adresu xxx","zapisz accu pod adres xxx","wprowadz do accu
pomiar z przetwornika xxx","sprawdz czy accu jest wieksze od komorki po
adresem xxx","skocz o 19 kroków do przodu" itd...

#3:
Czy ktoś może coś takiego już dłubał i ma jakieś uwagi ?

Dla mnie podstawowy problem to w tej chwili określić minimum zestawy
instrukcji wirtualnego assemblera z mozliwością rozbudowy w przyszłości.

PS. Rozwiązanie na sterownikach PLC nie wchodzi w grę, w środku musi być
masa matematyki na poziomie mnożeń i dzieleń. Ponadto PLC jest drogie :/

--
Sebastian Bialy - heby_at_nospam_poczta.onet.pl

Poprzedni Następny
Wiadomość
Spis treści
From: "Greg" <xgrzes_at_nospam_poczta.onet.pl>
Subject: Re: uC z językiem skryptowym
Date: Thu, 20 Jan 2005 09:54:54 +0100



a moze poszukaj cos o Basic Stamp?



Poprzedni Następny
Wiadomość
Spis treści
From: J.F. <jfox_xnospamx_at_nospam_poczta.onet.pl>
Subject: Re: uC z językiem skryptowym
Date: Thu, 20 Jan 2005 20:56:46 +0100


On Thu, 20 Jan 2005 09:54:54 +0100, Greg wrote:
a moze poszukaj cos o Basic Stamp?

Byl tez 8052 Basic

J.


Poprzedni Następny
Wiadomość
Spis treści
From: Albert Bartoszko <albertb_at_nospam_nt.kegel.com.pl>
Subject: Re: uC z =?ISO-8859-2?Q?j=EAzykiem_skryptowym?=
Date: Thu, 20 Jan 2005 11:48:23 +0100


Użytkownik Sebastian Bialy napisał:
Witam!

Jest sobie uC. W uC siedzi program, który jest niezmienny. Niestety
zewnątrzne zastosowanie uC jest nieco różne: konkretnie ma on się
zajmowac podejmowaniem decyzji i decyzje te mogą się zmieniać w
zalezności od konkretnego egzemplarza.

Chciałbym zrobić wobec tego coś takiego: ponieważ prędkość nie jest
krytyczna chcę zaszyć w pamięci Flash uC zestaw procedur, a w
zewnątrznym eepromie i2c coś w rodzaju skryptu, który z nich korzysta.
uC emulowałby taki wirtualny assembler wykonując krok po kroku
zewnątrzny program.

#1:
Czy istnieje jakiś taki gotowy jezyk ? Nie potrzebuje funkcjonalności
Byterun Java, mam na myśli coś znacznie prostszego.

#2:
Jesli nie istnieje, to będe musiał wymysleć. Wykombinowałem sobie to
tak, że wirtualna maszyna może mieć jeden akumulator i zestaw instrukcji
działających na adresach bezwzględnych. Na przykład "dodaj do accu
wartość z adresu xxx","zapisz accu pod adres xxx","wprowadz do accu
pomiar z przetwornika xxx","sprawdz czy accu jest wieksze od komorki po
adresem xxx","skocz o 19 kroków do przodu" itd...

#3:
Czy ktoś może coś takiego już dłubał i ma jakieś uwagi ?

Dla mnie podstawowy problem to w tej chwili określić minimum zestawy
instrukcji wirtualnego assemblera z mozliwością rozbudowy w przyszłości.

PS. Rozwiązanie na sterownikach PLC nie wchodzi w grę, w środku musi być
masa matematyki na poziomie mnożeń i dzieleń. Ponadto PLC jest drogie :/


Też myślę nad czymś takim i w wolnej chwili będę działał.
Moim pomysłem natomiast jest ograniczyć ten "assembler" do minimum.
Rozumiem to w ten sposób, żeby zaimplementować tylko instrukcję
warunkową i skok a całą resztę jako mapowane procedury i tak wpisywane
w uC. No może jeszcze jakąś pętlę.

Nasz "assembler" byłby wtedy mały, elastyczny i uniwersalny. Niestety
trochę proceduralny, bez zmiennych. Powinien być łatwy do napisania i
dobrze wykorzystywać swoje środowisko.
Zestaw instrukcji byłby wtedy częścią projektu, nie assemblera.

Albert.

Poprzedni Następny
Wiadomość
Spis treści
From: Sebastian Bialy <heby_at_nospam_poczta.onet.pl>
Subject: Re: uC z =?ISO-8859-2?Q?j=EAzykiem_skryptowym?=
Date: Thu, 20 Jan 2005 11:37:10 +0100


Albert Bartoszko wrote:
Też myślę nad czymś takim i w wolnej chwili będę działał.
Moim pomysłem natomiast jest ograniczyć ten "assembler" do minimum.

Dokładnie w tym kierunku zmierzam, na przykłąd 1 rejestr (akumulator) i
powiedzmy 16 komórek pamięci. Musze przemyśleć, czy to wystarczy. W
zasadzie to mój pomysł przypomina bardzo koprocesor matematyczny, tylko
bez stosu (ale może by tak zrobić stos ..., to by jeszcze bardziej
uprościło język).

Rozumiem to w ten sposób, żeby zaimplementować tylko instrukcję
warunkową i skok a całą resztę jako mapowane procedury i tak wpisywane
w uC. No może jeszcze jakąś pętlę.

No dokładnie, u mnie nawet bez pętli się obędzie (ale język by miał
możliwośc rozbudowy).

Nasz "assembler" byłby wtedy mały, elastyczny i uniwersalny. Niestety
trochę proceduralny, bez zmiennych. Powinien być łatwy do napisania i
dobrze wykorzystywać swoje środowisko.

Nie ma znaczenia jego wygląd i tak należało by napisać jakiś wyższego
poziomu, bo dłubanie w wirtualnym kodzie maszynowym może być trudne.
Choćby assembler, choć można coś w rodzaju prymitywnego basica.

Zestaw instrukcji byłby wtedy częścią projektu, nie assemblera.

Poniekąd. W ogóle oceniam, że mój jezyk poza liczeniem i decyzjami
korzysta wyłacznie z wbudowanych procedur w uC.

--
Sebastian Bialy - heby_at_nospam_poczta.onet.pl

Poprzedni Następny
Wiadomość
Spis treści
From: Albert Bartoszko <albertb_at_nospam_nt.kegel.com.pl>
Subject: Re: uC z =?ISO-8859-2?Q?j=EAzykiem_skryptowym?=
Date: Thu, 20 Jan 2005 12:29:34 +0100


Użytkownik Sebastian Bialy napisał:

Hmm, jest jeszcze jedna możiwość.
Zmienić uC na taki co z RAM'a program może wykonywać.
A potem tylko: z EEPROM do MEM, call MEM i hula.

Prawie jak PC-et z dyskietką ;-)

Albert

Poprzedni Następny
Wiadomość
Spis treści
From: Sebastian Bialy <heby_at_nospam_poczta.onet.pl>
Subject: Re: uC z =?ISO-8859-2?Q?j=EAzykiem_skryptowym?=
Date: Thu, 20 Jan 2005 12:12:15 +0100


Albert Bartoszko wrote:
Zmienić uC na taki co z RAM'a program może wykonywać.
A potem tylko: z EEPROM do MEM, call MEM i hula.

I wszem, ale tu jest jeden problem: zakładam, że jeśli popełnię błąd w
algorytmie na procesor wirtualny - cały system się nie powiesi się, w
szczególności, że mogę w procesorze reczywistym dokonać zabezpieczeń
przez sytuacjami niebezpiecznymi. Problem w tym, że kod wirtualny może
być pisany przez osoby nie mające o tym zbyt dużego pojęcia.

--
Sebastian Bialy - heby_at_nospam_poczta.onet.pl

Poprzedni Następny
Wiadomość
Spis treści
From: "Marek Dzwonnik" <mdz_at_nospam_WIADOMO_PO_CO_TO.message.pl>
Subject: =?iso-8859-2?Q?Re:_uC_z_j=EAzykiem_skryptowym?=
Date: Thu, 20 Jan 2005 12:46:53 +0100


Użytkownik "Sebastian Bialy" <heby_at_nospam_poczta.onet.pl> napisał w wiadomości
news:csnrcu$321$1_at_nospam_nemesis.news.tpi.pl

Czy istnieje jakiś taki gotowy jezyk ?

Forth? ;-)
Ja wiem, że to jezyk dla zapaleńców, ale jak już się ten zapał posiądzie, to
podobno nawet dosyć efektywny. Na pewno miałem w ręku jakąś implementrację
Forth-a na '51-kę.

--
Marek Dzwonnik, GG: #2061027 - zwykle jako 'niewidoczny'
(Uwaga Gadu-Gadulcowicze: Nie odpowiadam na anonimy.)



Poprzedni Następny
Wiadomość
Spis treści
From: Albert Bartoszko <albertb_at_nospam_nt.kegel.com.pl>
Subject: Re: uC z =?ISO-8859-2?Q?j=EAzykiem_skryptowym?=
Date: Thu, 20 Jan 2005 13:26:54 +0100


Użytkownik Marek Dzwonnik napisał:

Użytkownik "Sebastian Bialy" <heby_at_nospam_poczta.onet.pl> napisał w wiadomości
news:csnrcu$321$1_at_nospam_nemesis.news.tpi.pl


Czy istnieje jakiś taki gotowy jezyk ?


Forth? ;-)
Ja wiem, że to jezyk dla zapaleńców, ale jak już się ten zapał posiądzie, to
podobno nawet dosyć efektywny. Na pewno miałem w ręku jakąś implementrację
Forth-a na '51-kę.

http://www.rowley.co.uk/msp430/basic.htm

A tu BASIC na MSP430 ;-)

Albert

Poprzedni Następny
Wiadomość
Spis treści
From: Jan Dubiec <jdx_at_nospam_SPAMTRAP.slackware.pl>
Subject: Re: uC z =?iso-8859-2?Q?j=EAzykiem?= skryptowym
Date: Thu, 20 Jan 2005 13:08:39 +0000 (UTC)


Marek Dzwonnik wrote on Thu, 20 Jan 2005 12:46:53 +0100:
[.....]
Forth? ;-)
Ja wiem, że to jezyk dla zapaleńców, ale jak już się ten zapał posiądzie, to
podobno nawet dosyć efektywny. Na pewno miałem w ręku jakąś implementrację
Forth-a na '51-kę.
Ale używa Odwrotnej Notacji Polskiej która w Polsce chyba nie jest lubiana. :-)
Na comp.arch.embedded jest koleś który w Forth programował lalkę Barbie albo
Kena - nie pamiętam dokładnie. :-) A konkretniej, to pisał soft na jakieś
czetobitowe uC które napędzają to ustrojstwo.

Regards,
/J.D.


Poprzedni Następny
Wiadomość
Spis treści
From: Tawez <tawezBEZTEGO_at_nospam_IBEZTEGOop.pl>
Subject: Re: uC z =?ISO-8859-2?Q?j=EAzykiem_skryptowym?=
Date: Thu, 20 Jan 2005 15:55:25 +0100


Jan Dubiec napisał(a):
Marek Dzwonnik wrote on Thu, 20 Jan 2005 12:46:53 +0100:
[.....]

Forth? ;-)
Ja wiem, że to jezyk dla zapaleńców, ale jak już się ten zapał posiądzie, to
podobno nawet dosyć efektywny. Na pewno miałem w ręku jakąś implementrację
Forth-a na '51-kę.

Ale używa Odwrotnej Notacji Polskiej która w Polsce chyba nie jest lubiana. :-)

i słusznie, bo od Odwrotnej Notacji Polskiej
lepsza jest Notacja Polska ;)

programuję w PostScript to wiem :)))))))))))


--
Tawez

Poprzedni Następny
Wiadomość
Spis treści
From: Jan Dubiec <jdx_at_nospam_SPAMTRAP.slackware.pl>
Subject: Re: uC z =?iso-8859-2?Q?j=EAzykiem?= skryptowym
Date: Thu, 20 Jan 2005 16:07:29 +0000 (UTC)


Tawez wrote on Thu, 20 Jan 2005 15:55:25 +0100:
Jan Dubiec napisał(a):
[.....]
Ale używa Odwrotnej Notacji Polskiej która w Polsce chyba nie jest lubiana. :-)

i słusznie, bo od Odwrotnej Notacji Polskiej
lepsza jest Notacja Polska ;)
Nie, RPN jest lepsza: jest trochę bardziej czytelna ze względu na inne
położenie operatorów.

programuję w PostScript to wiem :)))))))))))
A to od kiedy PS używa PN a nie RPN? :-)

Regards,
/J.D.


Poprzedni Następny
Wiadomość
Spis treści
From: Tawez <tawezBEZTEGO_at_nospam_IBEZTEGOop.pl>
Subject: Re: uC z =?ISO-8859-2?Q?j=EAzykiem_skryptowym?=
Date: Thu, 20 Jan 2005 17:30:05 +0100


Jan Dubiec napisał(a):

Ale używa Odwrotnej Notacji Polskiej która w Polsce chyba nie jest lubiana. :-)

i słusznie, bo od Odwrotnej Notacji Polskiej
lepsza jest Notacja Polska ;)

Nie, RPN jest lepsza: jest trochę bardziej czytelna ze względu na inne
położenie operatorów.


programuję w PostScript to wiem :)))))))))))

A to od kiedy PS używa PN a nie RPN? :-)

och, koniecznie chciałem zabrać głos na grupie,
a czasami czuję się tak niekompetentny
że już wolę konfabulować w tematach bardziej OT ;)))))


PS. a propos PostScript.
Propozycja/prośba adresowana do robotyków między innymi
napisałem właśnie programik w PS do robienia tarcz enkoderów
(praktycznie dowolnych) i potrebuję beta testerów ;)
chętnych proszę o kontakt na priv.


--
Pozdrawiam
Tawez

Poprzedni Następny
Wiadomość
Spis treści
From: Jacek Czerwinski <jacek_delete_this_at_nospam_klik.rubikon.pl>
Subject: Re: uC z =?iso-8859-2?Q?j=EAzykiem?= skryptowym
Date: Thu, 20 Jan 2005 14:18:57 +0100


Thu, 20 Jan 2005 12:46:53 +0100, na pl.misc.elektronika, Marek Dzwonnik
napisał(a):

Użytkownik "Sebastian Bialy" <heby_at_nospam_poczta.onet.pl> napisał w wiadomości
news:csnrcu$321$1_at_nospam_nemesis.news.tpi.pl

Czy istnieje jakiś taki gotowy jezyk ?

Forth? ;-)
Ja wiem, że to jezyk dla zapaleńców, ale jak już się ten zapał posiądzie, to
podobno nawet dosyć efektywny. Na pewno miałem w ręku jakąś implementrację
Forth-a na '51-kę.

Lua ?
Stosową notację fortha nie każdy wytrzymuje. Nie wiem czy da się zrobic
port 16bit ale jestm ciekaw

Poprzedni Następny
Wiadomość
Spis treści
From: =?ISO-8859-2?Q?Pawe=B3_Cies=B3owski?=
Subject: Re: uC z =?ISO-8859-2?Q?j=EAzykiem_skryptowym?=
Date: Thu, 20 Jan 2005 13:20:35 +0100


Sebastian Bialy napisał(a):

#2:
Jesli nie istnieje, to będe musiał wymysleć. Wykombinowałem sobie to
tak, że wirtualna maszyna może mieć jeden akumulator i zestaw instrukcji
działających na adresach bezwzględnych. Na przykład "dodaj do accu
wartość z adresu xxx","zapisz accu pod adres xxx","wprowadz do accu
pomiar z przetwornika xxx","sprawdz czy accu jest wieksze od komorki po
adresem xxx","skocz o 19 kroków do przodu" itd...
Do prostych zastosowań wystarczą instrukcje arytmetyczne/logiczne i coś
do we/wy oraz instrukcja wywołania funkcji z flash'a. Ważne jest dla
celów rozwojowych w przyszłości jest przemyślenie binarnej reprezentacji
kodu instrukcji oraz trybów adresowania (zmienne i tablice).

#3:
Czy ktoś może coś takiego już dłubał i ma jakieś uwagi ?
Akurat udało mi się popełnić takie rozwiązanie, łącznie z kompilatorem
języka "php-like" dla serii modułów Ethernetowych. Obsługuje wywołania
funkcji z firmware modułu, funkcje użytkownika, zmienne lokalne, tablice
itp. Program jest wykonywany z pamięci I2C która także zawiera
filesystem dla serwera http. Szczegóły na stronie
www.emetec.com.pl/pl/spike.php.

W tym rozwiązaniu jest wykorzytana tzw. maszyna stosowa (bez rejestrów)
wyłącznie stos który oczywicie musi być odpowiednio duży. Program
wykonuje operacje arytmetycze, logiczne przez odkładanie na stosie
argumentów oraz wyniku operacji np: param1==param2 w asm będzie:
PUSH parm1
PUSH para2
EQU
instrukcja EQU pobiera dwie wartości ze stosu a umieszcza z powrotem
wynik wykonania - szczt stosu pełni rolę akumulatora. Wartości param1/2
to jak widać stałe lecz można także operować na wartościach tylko należy
je załadować na stos instrukcją "IN adres" czyli wyrażenie
var1=(var1+param2)/param3 można zapisać asm jako:
IN var1
PUSH param2
ADD
PUSH param3
DIV
OUT var1
i na szczycie stosu otrzymamy wynik, który można wysłać do pamięci
zmiennych przez instrukcję "OUT adres", która także zdejmuje wartość ze
stosu i ładuje do pamięci zmiennych.

Wywołanie procedury z pamieci flash jest realizowane następująco
(procedura może mieć parametry)
PUSH param1 ;przekaznie parmetru przez stos
CALL funcnum ;funcnum to index do tablicy funkcji we flash'u
FIX -1 ;przesuniecie "ręczne" {usunięcie parametru)

Dużą zaletą tego rozwiązania jest prostota tworzenia kompilatora. Także
łatwo wykryć trakcie wykonania sytuacje awaryjne przez obserwację
wirtualnego wskaźnika stosu.

Pozdrawiam
Paweł Ciesłowski
---
"Ci co mówią nie wiedzą, ci co wiedzą nie mówią."

Poprzedni Następny
Wiadomość
Spis treści
From: Sebastian Bialy <heby_at_nospam_poczta.onet.pl>
Subject: Re: uC z =?ISO-8859-2?Q?j=EAzykiem_skryptowym?=
Date: Thu, 20 Jan 2005 20:00:14 +0100


Paweł Ciesłowski wrote:
Do prostych zastosowań wystarczą instrukcje arytmetyczne/logiczne i coś
do we/wy oraz instrukcja wywołania funkcji z flash'a. Ważne jest dla
celów rozwojowych w przyszłości jest przemyślenie binarnej reprezentacji
kodu instrukcji oraz trybów adresowania (zmienne i tablice).

Myślę, że akurat zakładając rozmiar definicji instrukcji na jeden bajt -
mam sporą przestrzeń.

Akurat udało mi się popełnić takie rozwiązanie, łącznie z kompilatorem
języka "php-like" dla serii modułów Ethernetowych. Obsługuje wywołania
funkcji z firmware modułu, funkcje użytkownika, zmienne lokalne, tablice
itp. Program jest wykonywany z pamięci I2C która także zawiera
filesystem dla serwera http. Szczegóły na stronie
www.emetec.com.pl/pl/spike.php.

Ładne, choć w moim przypadku jest nieco inaczej - przejrzystośc tego
wirtualnego kodu powinna być możlwie mała, ale na tyle czytelna, żebym
się w tym połapał ;) Chodzi o utrudnienie grzebania w domowych warunkach.

W tym rozwiązaniu jest wykorzytana tzw. maszyna stosowa (bez rejestrów)
wyłącznie stos który oczywicie musi być odpowiednio duży.

Zastanawiam się nad takim rozwiązaniem zamist banku rejestrów. Z moich
szacunków wynika jednak, że potrzebuje maksimum 16 komórek pamieci na
raz. Kod przewiduje adresowanie 256. Być może stos będzie dodatkiem do
jezyka a nie integralną cześcią. W ogólności źle mi się pisze stosowo,
ale to pewno skrzywienie koderskie z MC68000 :) Ci co pisali na x86
pewno mają większą wprawę ;)

Dużą zaletą tego rozwiązania jest prostota tworzenia kompilatora. Także
łatwo wykryć trakcie wykonania sytuacje awaryjne przez obserwację
wirtualnego wskaźnika stosu.

Kompilator nie będzie chyba na razie potrzebny, jeśli język będzie
prosty wystarczy do niego asembler.

--
Sebastian Bialy - heby_at_nospam_poczta.onet.pl

Poprzedni Następny
Wiadomość
Spis treści
From: =?ISO-8859-2?Q?Pawe=B3_Cies=B3owski?=
Subject: Re: uC z =?ISO-8859-2?Q?j=EAzykiem_skryptowym?=
Date: Thu, 20 Jan 2005 21:14:28 +0100


Sebastian Bialy napisał(a):

Ładne, choć w moim przypadku jest nieco inaczej - przejrzystośc tego
wirtualnego kodu powinna być możlwie mała, ale na tyle czytelna, żebym
się w tym połapał ;) Chodzi o utrudnienie grzebania w domowych warunkach.
Hmm... ale przecież w docelowym urządzeniu bedzie tylko binarna
reprezentacja kodu wirtualnej maszynki. Bez znajomości implementacji
cieżko bedzie rozgryźć za co który bajt skryptu odpowiada. Nawet trudzo
będzie wskazać gdzie kod się zaczyna :-)

Zastanawiam się nad takim rozwiązaniem zamist banku rejestrów. Z moich
szacunków wynika jednak, że potrzebuje maksimum 16 komórek pamieci na
raz. Kod przewiduje adresowanie 256.
Jako komórkę możesz także potraktować odwołanie do ADC lub pinu I/O (np
adresy 0-0x10 ram, 0x20-0x30 kanały ADC itp) z czasem przestrzeń
adresowa może się skurczyć :-)

Być może stos będzie dodatkiem do jezyka a nie integralną cześcią.
Stos w takim zastosowaniu służy głownie do przekazywania parametrów i
wyliczania wyrażeń.Dla przykładu konstrukcja operacji np ADD jest w
takim przypadku bardzo prosta:
// definicje
#define POP(x) x=*(sptr++)
#define PUSH(x) *(--sptr)=x
uint8t a;
uint8t b;
//...VM func...
if (opcode==OP_ADD){
POP(a);
POP(b);
PUSH(a+b);
};
//...VM func...

W innym przypadku będziesz zmuszony do przekazania adresu operandu albo
w kodzie instrukcji (znacznie ograniczy ilość instrukcji) lub kolejny
bajt będzie adresem operandu (ewentualnie stałą). I tutaj bedziesz
musiał zdefiniowac kod ADD (adres) oraz ADD (stała), może być jako
uzupełnienie także ADD (numer rejestru).

Kompilator nie będzie chyba na razie potrzebny, jeśli język będzie
prosty wystarczy do niego asembler.

Assembler też jest kompilatorem. Pracuje z kodem źródłowym w postaci
ciągów ASCII, wymaga parsera który zamieni ciag np. PSH 01 lub PUSH 01
na binarnie np 05 01 lub dla szesnastu bitów argumentu 05 01 00.
Assembler także wymaga obsługi tablicy symboli itp.

Pozdrawiam
Paweł Ciesłowski
---
"Ci co mówią nie wiedzą, ci co wiedzą nie mówią."

Poprzedni Następny
Wiadomość
Spis treści
From: J.F. <jfox_xnospamx_at_nospam_poczta.onet.pl>
Subject: Re: uC z językiem skryptowym
Date: Thu, 20 Jan 2005 22:43:01 +0100


On Thu, 20 Jan 2005 20:00:14 +0100, Sebastian Bialy wrote:
Ładne, choć w moim przypadku jest nieco inaczej - przejrzystośc tego
wirtualnego kodu powinna być możlwie mała, ale na tyle czytelna, żebym
się w tym połapał ;) Chodzi o utrudnienie grzebania w domowych warunkach.

FORTH jest dla Ciebie.
Jezyk wybitnie "write only" :-)


J.


Poprzedni Następny
Wiadomość
Spis treści
From: point <no_at_nospam_mail.net>
Subject: Re: uC z =?ISO-8859-2?Q?j=EAzykiem_skryptowym?=
Date: Thu, 20 Jan 2005 20:45:16 +0100


Sebastian Bialy wrote:

#2:
Jesli nie istnieje, to będe musiał wymysleć. Wykombinowałem sobie to
tak, że wirtualna maszyna może mieć jeden akumulator i zestaw instrukcji
działających na adresach bezwzględnych. Na przykład "dodaj do accu
wartość z adresu xxx","zapisz accu pod adres xxx","wprowadz do accu
pomiar z przetwornika xxx","sprawdz czy accu jest wieksze od komorki po
adresem xxx","skocz o 19 kroków do przodu" itd...

#3:
Czy ktoś może coś takiego już dłubał i ma jakieś uwagi ?

Ja stworzyłem własny język skryptowy dla PIC18. Na PC pisze się kod
źródłowy w języku strukturalnym podobnym do C (gramatyka prawie w
całości została zerżnięta z ANSI C:) i kompiluje do kodu pośredniego
(pcode - rodzaj asemblera) wykonywanego instrukcja po instrukcji przez
interpreter (technologia Virtual Stack Machine VSM). Skompilowany skrypt
w postaci binarnej siedzi we FLASH proca.
Całość ma działać podobnie jak skrypt w modułach GSM Sony-Ericsson GR47.
Interpreter wyciska jakieś 20k instr./sek. na marnych 5 MIPS PIC18 ale w
planach jest migracja na ARM7 hi hi:)
Przykład:
1. Źródło:

main
{
print (1+2*3, 0x00);
}

2. pcode:
push 1
push 2
push 3
mul
add
push 0
print
exit