Pokud si to po těch mnoha letech dobře pamatuju, v ZX-Spectru CORDIC použit nebyl.
Steven Vickers tam implementoval tzv. "calculator", pomocí kterého se goniometrické funkce počítaly s využitím Taylorova polynomu.
Nevynikalo to rychlostí, ale calculator se velmi snadno používal ve vlastním kódu - díky němu bylo třeba možné velmi jednoduše počítat s reálnými čísly nejenom v Basicu.
Je to fakt dávno, ale pokud si vzpomínám, měl calculator zásobníkovou architekturu a byl volán pomocí RST #cislosinepamatuju.
Nebyly to Taylorovy, ale Čebyševovy polynomy a číslo RST je 28 (hexa) :-). Viz http://softhouse.speccy.cz/documents/download/ZX_ROM.pdf strana 217.
V ROM nebyl, ale jinak se i na Z80 pouzival. Tady je asi trosku modernejsi verze:
http://www.andreadrian.de/oldcpu/Z80_number_cruncher.html#mozTocId663023
Bude to asi rychlejsi nez vypocty Cebysevova polynomu, presnost volitelna.
Nekde je i varianta pro BOBO pro pocitace z CSSR :-)
S klony 8052 jsem si uzil mnoho.
Tahle architektura se mi libila pro svuj assembler a bitove operace.
Nejzajimavejsi klon jsem pouzil na ctecku stravenek - delala scan a ocr a ven posilala po serialce nebo usb uz dekodovany string.
Pouzil jsem na to uPSD3234 od ST. Melo to 8KiB sram a 256KiB flash. Z periferek to melo USB, I2C, ADC, DDC, PWM, 2 UARTy a pgogramovatelne logicke pole s 16 makrocellami a 3000 hradly.
No, uzil jsem si s tim, ale kdyz se na to divam zpetne, byla to spatna volba. Uz v te dobe byly podstatne lepsi microcontrollery.
Tohle jsem samozrejme neprogramoval v assembleru, bylo to v C a kompiloval jsem to pomoci SDCC kompilatoru. Ten mel mimo jine spoustu bugu, takze nektere konstrukce byly stejne napsany v assembleru, i kvuli rychlosti.
Program byl velmi silne optimalizovany pro tuto architekturu, pamet byla vyuzita do skoro posledniho bitu. Byla to dost velka silenost.
No ona je to klasika, architektura od Intelu :/ Pomalý, omezení paměti, brzda v podobě externích pamětí, vyšší jazyky zkryplený a ASM nepřenositelný. Divím se, že si originál vystačil jenom s jedním napájecím napětím.
Roky doufám, že tahle architektura brzo skončí v muzeu, a moje přání furt není vyslyšeno a furt se s tím zgarbem dělají noví a noví brouci. :(
Jenomže to furt asiati cpou do brouků, jako je řadič kapacitního touchscreenu FT5x06 od FocalTECHu, starší RF čipy od Nordiců atd. :(
Jasně, že normálně by 51ku použil jenom šílenec blbej jak papuč, ale když někde není alternativa, je možnost upgrade FW a je potřeba trochu přiohnout funkci, tak začíná BDSM...
Ze se tak ptam (fakt me to zajima) - co bylo tak pekne na tom assembleru? Ze existoval jen jediny rozumny adresovy registr DPTR (naplnovany pres hodnich/spodnich osm bitu), polovina RAM nebyla adresovatelna primo a pro vetsi cipy (ne 51/52) se stejne muselo adresovat silene pres ruku? Skoda, ze se neprosadil Z8, ten mel lepsi reseni.
(btw: 68HC11 byla taky dost hruza, kdyz jsme u toho)
Díky za pěkný příklad, mám dost podobné zkušenosti. Právě u těchto švábů s trošku větší RAM a ROM/Flash se už ukazuje zastaralost 8051/52, hlavně při adresování. Stačí se podívat, jaké cviky musí překladač dělat i při takové maličkosti, jako je adresování polí nebo struktur (potom je docela zajímavé zjistit, že ten řadič USB zabírá větší plochu čipu než samotné jádro 51čky :-)
To jo, ale to nic nerika o tom, ze nasadit na to C prekladac je dost opruz. Samozrejme pokud mas par lidi, co s 51 vysivaji v ASM a nemas problem takovy (zdlouhavejsi) vyvoj zaplatit, tak ok, ale ne kazdej ma v logu VW :-) Ale to plati pro IT obecne - dnesni pocitace jsou vetsinou az "zbytecne" vykonne a maji velkou RAM, ovsem malokdo si muze dovolit vyvoj v ASM a zmensit naroky.
Já to chápu a nemám nic proti *původní* řadě se 128 nebo 256 bajty RAM a (tuším) čtyřmi kilobajty (EP)ROM. To byla celkem pohodička, typicky se to programovalo v assembleru a kdo potřeboval externí RAM/ROM, tak stejně skončil s dost neoptimálním řešením (další dva až čtyři švábi, to se elegance MCU trošku ztrácí). Ještě chápu větší ROM, nějaké převodní tabulky a tak se hodí.
Ovšem ve chvíli, kdy se ten čip rozšíří na 64 KB RAM a totéž s Flash (tedy ROM) a začne se masivně používat céčko, tak to přesáhne možnosti původní 51 - málo registrů, velmi omezené možnosti adresování čehokoli mimo prvních 128 bajtů, většina instrukcí vyžaduje pro jeden operand akumulátor, takže se pořád přesouvají data (je asi fajn mít spoustu jednobajtových instrukcí, ale v tom množství MOVů se už elegance ztrácí, ostatně jedno z častých rozšíření 51 je dalších cca 250 instrukcí, které rozšíří možnosti R0-R7). Při pohledu na generovaný kód je to bída, hlavně v porovnání s konkurencí (H8, AVR), kde se už od začátku soustředili na instrukční sadu vhodnou pro C-like překladače.
Ve zkratce 51 je mrtvá a Ewarp a podobné křeče to prostě nezmění. Tedy poměrně zbytečný článek.
Dnes doporučuji i přeskočit cokoliv v 8bit (přestože třeba AVR jsem měl fakt rád) a jít rovnou do Cortexu.
můžem o tom diskutovat, můžem se přít, ale na holém faktu nic nezměníme.
No ono je to jednoduse tak, jak pise Petr M o par odpovedi vys. Kdyz mas svaba, kterej ti po vsech strankach vyhovuje (IO moduly) a je jen s 51, tak to prekousnes a pouzijes. Ostatne pokud v automotive (napriklad) potrebujes tim svabem stahovat vokynka a po LIN nebo CAN nahlasit "otevreno" "zavreno" "asi je tam hlava", tak na to Cortex neni potreba (i kdyz ja ho mam rad, hlavne ty nizsi rady M0+).
Co uz mi neni moc jasny je snaha na 51 roubovat desitky kilobajtu RAM/ROM, to je uz daleko mimo rozumne moznosti toho jadra.
Jo a nezapomenme na 16bitove MCU, taky umiraji umiraji umiraji a budou tady jeste dlouho :/