Juz tego nie pamietam ale podobno c64 mial tylko 3 rejestry a x i y 9pamietam ze byl
to wlasnie dosyc ladny assembler nie to co Z80)

zastanawiam sie jak dokladnie powinien wygladac
maksymalnie prosty assembler ale zarazem funkcjonalny, cos takiego jak asm na c64
tylko
moze lkko poprawionego (chodzi o cos w rodzaju
wirtualnej maszyny nieco mocniejszej moze nic c64
ale w podobnym stylu)

chyba moglbym przyjac jakas arbitralną wielkosc slowa ktore rownoczesnie byloby tez
wielkoscia
bajtu, na przyklad 20 bitów czy cos w tym stylu, mozna ot tej konkretnej ilosci
abstrahowac i przyjac na przyklad te 20)

ale pozatym co powinno tu byc?

ile rejestrow? jeden? dwa ? trzy?

na pewno powinien bys mov (ld/st), prosta arytmetyka add/sub/mul/div, adresowanie
'tablicowe', i skoki (warunkowe),
procz tego prztdalby sie cal i ret
ale czy cos jeszcze?

do góry

W dniu niedziela, 12 października 2014 12:49:23 UTC+2 użytkownik firr napisał:
> Juz tego nie pamietam ale podobno c64 mial tylko 3 rejestry a x i y 9pamietam ze
byl to wlasnie dosyc ladny assembler nie to co Z80)
>
>
>
> zastanawiam sie jak dokladnie powinien wygladac
>
> maksymalnie prosty assembler ale zarazem funkcjonalny, cos takiego jak asm na c64
tylko
>
> moze lkko poprawionego (chodzi o cos w rodzaju
>
> wirtualnej maszyny nieco mocniejszej moze nic c64
>
> ale w podobnym stylu)
>
>
>
> chyba moglbym przyjac jakas arbitralną wielkosc slowa ktore rownoczesnie byloby tez
wielkoscia
>
> bajtu, na przyklad 20 bitów czy cos w tym stylu, mozna ot tej konkretnej ilosci
abstrahowac i przyjac na przyklad te 20)
>
>
>
> ale pozatym co powinno tu byc?
>
>
>
> ile rejestrow? jeden? dwa ? trzy?
>

a moze zero? ciezko sie zdecydowac w takich sprawach

screenx 100
screeny 100
color 0

i 0

HERE
screen+i color
i i+1
jmp i<screenx HERE

..hmm
>
>
> na pewno powinien bys mov (ld/st), prosta arytmetyka add/sub/mul/div, adresowanie
>
> 'tablicowe', i skoki (warunkowe),
>
> procz tego prztdalby sie cal i ret
>
> ale czy cos jeszcze?

do góry

W dniu 2014-10-12 o 12:49, firr pisze:
> Juz tego nie pamietam ale podobno c64 mial tylko 3 rejestry a x i y 9pamietam ze
byl to wlasnie dosyc ladny assembler nie to co Z80)
>
> zastanawiam sie jak dokladnie powinien wygladac
> maksymalnie prosty assembler ale zarazem funkcjonalny, cos takiego jak asm na c64
tylko
> moze lkko poprawionego (chodzi o cos w rodzaju
> wirtualnej maszyny nieco mocniejszej moze nic c64
> ale w podobnym stylu)
>
> chyba moglbym przyjac jakas arbitralną wielkosc slowa ktore rownoczesnie byloby tez
wielkoscia
> bajtu, na przyklad 20 bitów czy cos w tym stylu, mozna ot tej konkretnej ilosci
abstrahowac i przyjac na przyklad te 20)
>
> ale pozatym co powinno tu byc?
>
> ile rejestrow? jeden? dwa ? trzy?
>
> na pewno powinien bys mov (ld/st), prosta arytmetyka add/sub/mul/div, adresowanie
> 'tablicowe', i skoki (warunkowe),
> procz tego prztdalby sie cal i ret
> ale czy cos jeszcze?
>


Assembler zależy od konkretnego procesora, bo to tylko wygodny zapis
języka maszynowego (pomijam udogodnienia typu etykiety itp.). Zamiast
zastanawiać się nad assemblerem, trzeba zastanowić się nad konstrukcją
procesora. IMHO gotowych rozwiązań nie brakuje, jest dużo "małych"
mikrokontrolerów takich jak wszelkiej maści Atmegi, PIC, klony 8051,
klony m64k (na przykład Freescale) czy ARM-y. Jeśli to za mało, to jest
wielu hobbystów-amatorów projektujących własne procesory czy koprocesory
wykorzystując układy FPGA (opencore.org) czy nawet... budujących własne
procesory z układów TTL, chociażby słynny Magic-1 zbudowany przez
jednego z inżynierów Google
http://www.youtube.com/watch?v=0jRgpTp8pR8
Warto obejrzeć ten filmik, bo to uzmysławia jak trzeba różne rzeczy
pogodzić (z jednej strony jak najprostszy CPU, z drugiej strony jak
najbardziej funkcjonalny, do tego trzeba zrobić kompilator na przykład
C, napisać system operacyjny itd.).
Teoretycznie wystarcza jedna instrukcja :D
http://en.wikipedia.org/wiki/One_instruction_set_com
puter
--
Pozdrawiam
Piotr

do góry

W dniu niedziela, 12 października 2014 18:25:37 UTC+2 użytkownik Piotr napisał:
> W dniu 2014-10-12 o 12:49, firr pisze:
>
> > Juz tego nie pamietam ale podobno c64 mial tylko 3 rejestry a x i y 9pamietam ze
byl to wlasnie dosyc ladny assembler nie to co Z80)
>
> >
>
> > zastanawiam sie jak dokladnie powinien wygladac
>
> > maksymalnie prosty assembler ale zarazem funkcjonalny, cos takiego jak asm na c64
tylko
>
> > moze lkko poprawionego (chodzi o cos w rodzaju
>
> > wirtualnej maszyny nieco mocniejszej moze nic c64
>
> > ale w podobnym stylu)
>
> >
>
> > chyba moglbym przyjac jakas arbitralnďż˝ wielkosc slowa ktore rownoczesnie byloby
tez wielkoscia
>
> > bajtu, na przyklad 20 bit�w czy cos w tym stylu, mozna ot tej konkretnej ilosci
abstrahowac i przyjac na przyklad te 20)
>
> >
>
> > ale pozatym co powinno tu byc?
>
> >
>
> > ile rejestrow? jeden? dwa ? trzy?
>
> >
>
> > na pewno powinien bys mov (ld/st), prosta arytmetyka add/sub/mul/div, adresowanie
>
> > 'tablicowe', i skoki (warunkowe),
>
> > procz tego prztdalby sie cal i ret
>
> > ale czy cos jeszcze?
>
> >
>
>
>
>
>
> Assembler zale�y od konkretnego procesora, bo to tylko wygodny zapis
>
> j�zyka maszynowego (pomijam udogodnienia typu etykiety itp.). Zamiast
>
> zastanawiaďż˝ siďż˝ nad assemblerem, trzeba zastanowiďż˝ siďż˝ nad konstrukcjďż˝
>
> procesora. IMHO gotowych rozwi�za� nie brakuje, jest du�o "ma�ych"
>
> mikrokontroler�w takich jak wszelkiej ma�ci Atmegi, PIC, klony 8051,
>
> klony m64k (na przyk�ad Freescale) czy ARM-y. Je�li to za ma�o, to jest
>
> wielu hobbyst�w-amator�w projektuj�cych w�asne procesory czy koprocesory
>
> wykorzystuj�c uk�ady FPGA (opencore.org) czy nawet... buduj�cych w�asne
>
> procesory z uk�ad�w TTL, chocia�by s�ynny Magic-1 zbudowany przez
>
> jednego z in�ynier�w Google
>
> http://www.youtube.com/watch?v=0jRgpTp8pR8
>
> Warto obejrze� ten filmik, bo to uzmys�awia jak trzeba r�ne rzeczy
>
> pogodziďż˝ (z jednej strony jak najprostszy CPU, z drugiej strony jak
>
> najbardziej funkcjonalny, do tego trzeba zrobi� kompilator na przyk�ad
>
> C, napisaďż˝ system operacyjny itd.).
>
> Teoretycznie wystarcza jedna instrukcja :D
>
> http://en.wikipedia.org/wiki/One_instruction_set_com
puter
>

ja bardziej mysle o maszynie wirtualnej badz 'emulatorze wymyslonego procesora'
(jesli miedzy jednym a drugim jest jakas roznica bo nie wiem),
bardziej mi w sumie chodzi o emulator - z emulatorem jest tylko ten problem ze nie
jestem pewien czy i jak nalezy zapewnic jakąś czasową
stabilność takiego emulatora tak by na przyklad
jeden cykl zajmowal dokladnie iles czasu i by to wszystko wogole nie 'plywało' w
czasie
(nie ejstem pewien czy to jest realny problem czy tylko moj teoretyczny wymyslony bo
widzialem emulatory c64 i nic nie plywalo - z drugiej strony nawet czyste winapowskie
natywne aplikacje chyba nieco plywają w czasie 9moga sie ciac jak film) tak ze nie
wiem)

co do asemblera to to co powyzej napisalem wydaje mi sie jak na razie okay (z lekkimi
poprawkami), czyli ogolnie prosty asm wogole bez rejestrow

do góry

W dniu 2014-10-12 o 18:54, firr pisze:
> ja bardziej mysle o maszynie wirtualnej badz 'emulatorze wymyslonego procesora'
(jesli miedzy jednym a drugim jest jakas roznica bo nie wiem),
> bardziej mi w sumie chodzi o emulator - z emulatorem jest tylko ten problem ze
nie jestem pewien czy i jak nalezy zapewnic jakąś czasową
> stabilność takiego emulatora tak by na przyklad
> jeden cykl zajmowal dokladnie iles czasu i by to wszystko wogole nie 'plywało' w
czasie
> (nie ejstem pewien czy to jest realny problem czy tylko moj teoretyczny wymyslony
bo widzialem emulatory c64 i nic nie plywalo - z drugiej strony nawet czyste
winapowskie natywne aplikacje chyba nieco plywają w czasie 9moga sie ciac jak film)
tak ze nie wiem)
>
> co do asemblera to to co powyzej napisalem wydaje mi sie jak na razie okay (z
lekkimi poprawkami), czyli ogolnie prosty asm wogole bez rejestrow
>

Oczywiście może być procesor bez rejestrów (w tym sensie, że można
potraktować całą pamięć RAM jako rejestry). W fizycznych procesorach
stosuje się rejestry ze względu na szybkość działania. W ogólności nie
musisz się bawić w "dyscyplinę czasową" poszczególnych instrukcji,
emulatory C64 to stosują, bo chodzi po prostu o emulację konkretnego
urządzenia (a więc między innymi o to aby programy chodziły tak samo jak
na oryginalnym C64 a nie 1000 razy szybciej), no i w C64 stosowało się
cyklowanie oraz wykorzystywano specyficzne zachowania zarówno procesora
jak i układów peryferyjnych - emulator który tego nie odzwierciedla, nie
będzie pozwalał na uruchomienie wielu programów. Obejrzyj sobie
http://www.youtube.com/watch?v=ZsRRCnque2E i zobacz jakie tricki
stosowali (i nadal stosują) programiści na C64, emulator musi być tak
napisany, aby te tricki działały, bo inaczej będzie kiepskim emulatorem.
W swoim "wymyślonym" procesorze nie musisz się w takie rzeczy bawić
jeśli nie będzie to potrzebne.

--
Pozdrawiam
Piotr

do góry

W dniu niedziela, 12 października 2014 20:13:07 UTC+2 użytkownik Piotr napisał:
> W dniu 2014-10-12 o 18:54, firr pisze:
>
> > ja bardziej mysle o maszynie wirtualnej badz 'emulatorze wymyslonego procesora'
(jesli miedzy jednym a drugim jest jakas roznica bo nie wiem),
>
> > bardziej mi w sumie chodzi o emulator - z emulatorem jest tylko ten problem ze
nie jestem pewien czy i jak nalezy zapewnic jak�� czasow�
>
> > stabilno�� takiego emulatora tak by na przyklad
>
> > jeden cykl zajmowal dokladnie iles czasu i by to wszystko wogole nie 'plywa�o'
w czasie
>
> > (nie ejstem pewien czy to jest realny problem czy tylko moj teoretyczny wymyslony
bo widzialem emulatory c64 i nic nie plywalo - z drugiej strony nawet czyste
winapowskie natywne aplikacje chyba nieco plywajďż˝ w czasie 9moga sie ciac jak film)
tak ze nie wiem)
>
> >
>
> > co do asemblera to to co powyzej napisalem wydaje mi sie jak na razie okay (z
lekkimi poprawkami), czyli ogolnie prosty asm wogole bez rejestrow
>
> >
>
>
>
> Oczywi�cie mo�e by� procesor bez rejestr�w (w tym sensie, �e mo�na
>
> potraktowa� ca�� pami�� RAM jako rejestry). W fizycznych procesorach
>
> stosuje si� rejestry ze wzgl�du na szybko�� dzia�ania. W og�lno�ci
nie
>
> musisz si� bawi� w "dyscyplin� czasow�" poszczeg�lnych instrukcji,
>
> emulatory C64 to stosujďż˝, bo chodzi po prostu o emulacjďż˝ konkretnego
>
> urz�dzenia (a wi�c mi�dzy innymi o to aby programy chodzi�y tak samo jak
>
> na oryginalnym C64 a nie 1000 razy szybciej), no i w C64 stosowa�o si�
>
> cyklowanie oraz wykorzystywano specyficzne zachowania zar�wno procesora
>
> jak i uk�ad�w peryferyjnych - emulator kt�ry tego nie odzwierciedla, nie
>
> b�dzie pozwala� na uruchomienie wielu program�w. Obejrzyj sobie
>
> http://www.youtube.com/watch?v=ZsRRCnque2E i zobacz jakie tricki
>
> stosowali (i nadal stosuj�) programi�ci na C64, emulator musi by� tak
>
> napisany, aby te tricki dzia�a�y, bo inaczej b�dzie kiepskim emulatorem.
>
> W swoim "wymy�lonym" procesorze nie musisz si� w takie rzeczy bawi�
>
> je�li nie b�dzie to potrzebne.
>
>

chodzi mi o to by jednak po prostu emulator "nie ciął" (nawet minimalnie) - i nie
wiem jak to zapewnic
zasadniczo to czas w emulatorze tez sie emuluje
i o tyle taki emulator moze dowolnie ciac itd i bedzie doskonale wmulowal - ale
jesliby to mial byc dokladny "fizycznie" emulator to nie powinien ciąć i dzialac
dokladnie co do mikrosekundy zgodnie z tym jak dziala dizyczna maszyna - nie wiem
wlasnie jak to sie robi
taka doskonale fizyczna emulacje (i na ile to jest wazne) -
z programami na peceta to jest wlasnie straszne ze czasem tną

do góry

tylko w sumie ta skladnie z symbolami wyglada na niedobrą, moze jednak lepszy bylby
klasyczny assembler cos w stylu



mv screenx 1000
mv screeny 1000
mv color 0
mv adr screen_start
mv j 0
:v
mv i 0
:h
ad adr i
mv [adr] color
jl i screenx :h
ad adr

tutaj niedokonczony przyklad, z dwuliterowymi
opcodami, niejasne jest dla mnie np
1) jaka skladnie powinna miec etykieta
2) jaka skladnie powinno miec pisanie pod adres
3) czy z branchów robic dwie instrukcje compare i warunkowy_jump czy jedna
trojkargumentową

pozatym ciekawostka tutaj mialem napisac petle do szyczczenia akranu na czarno (ale
nie chcialo mi sie konczyc) taka petla w takim asmie (ktory roboczo moge nazwac 2a
lub AA)
wygladalaby inaczej niz w typowym c bo w asmie nie chce sie chyba pisac mnozenia,
potrzebne jest tylko wylacznie dodawanie (z tym ze czasem dodawanie ujemnej i wlasnie
ciekawostka - nie wiem czy takie dodawanie ujemnej mozna zrobic wylcznie po stronie
programisty konwencją czy tez potrzebna jest jakakolwiek swiadomosc ze strony
procesora ze to jest cos innego niz zwykle dodawanie), w pewnym sensie kuszace jest
by pisac w takim asmie wylacznie z dodawaniem

(fir)

do góry

> nie wiem czy takie dodawanie ujemnej mozna zrobic wylcznie po stronie programisty
konwencją czy tez potrzebna jest jakakolwiek swiadomosc ze strony procesora ze to
jest cos innego niz zwykle dodawanie),

o ile tak jest - tj tak ze odejmowanie daje sie zrealizowac na procesorze wylacznie
z operacją dodawania (gdzie ujemna na przyklad -90 to "max - 90 +1 " (czyli
powiedzialbym "omax-dodatnia" gdzie omax to max +1 np 256 dla bajtu) to wynika z tego
ze w asemblerze nie ma czegos takiego jak signed int, unisigned int
jest tylko jeden typ ktory jest jakby sumą
signed i unsigned a czy konkretna wartosc jest signed czy unsigned zalezy od
kontekstu kodu

- bardzo wazny prosty fakt ale nieststy jakios w zyciu mnie ta swiadomosc (ze tak
chyba jest)
mnie omijala - o ile tak to troche znaczy ze
trzeba zwerufikowac moze swoje podejscie do typow signed i unsigned w c, byc moze
nawet
mozna powiedziec ze cos z nimi jest nie tak
(choc tu to nie wiem, byc moze sa ok zeby informowac kompilator o tych kontekstach
tylo nalezy czasem wykorzystywac rzutowania by miec dostep do tego wiekszego typu
(tymczasowo mozna nazwac "signed unsigned int" czy jakos inaczej)

do góry

> nazwac "signed unsigned int" czy jakos inaczej)

w sumie przy takich zlozeniach to np taki bajt jest nie tylko suma signed i unsigned
ale nawet sumą plus signed i minus unsigned, czyli jeden
bajt moze przechowywac np wartosci od -255 do 255

do góry

Dnia Mon, 13 Oct 2014 05:25:56 -0700 (PDT), firr napisał(a):

>> nazwac "signed unsigned int" czy jakos inaczej)
>
> w sumie przy takich zlozeniach to np taki bajt jest nie tylko suma signed i
unsigned ale nawet sumą plus signed i minus unsigned, czyli jeden
> bajt moze przechowywac np wartosci od -255 do 255

Teraz to juz przechodzisz samego siebie, zaslugujesz juz na wielkie Ś przed swoim
nickiem!
:-)

--
pozdro
R.e.m.e.K

do góry