Příspěvky

166

Odkladiště / Re:Kvalitní elektrokoloběžka

« kdy: 25. 10. 2021, 12:35:55 »

Pri nejakem padu/narazu se toho muze stat hodne, hlavne sedicim "ajtakum". Dopoucuji ctvrty - chmelovy odstavec https://artax.karlin.mff.cuni.cz/~mper7437/MATFYZAK.HTML

Jel jsem takhle jednou na kole lesem, opravdu pomalu. Najel jsem na malou vetev, mezi draty mi skocila jeji cast, kolo se celkem prudce zastavilo. Nespadnul jsem, jen mne to hodilo podivne az nekam nad riditka. Najednou citim hroznou bolest, prava ruka mi planda. Jak jsem nechapal co se deje, zkusil jsem s ni druhou rukou pohnout abych videl co se deje. Lup, a naskocila v rameni zpatky. Celkem dlouho to bolelo, ale lepsilo se to, tak jsem se obesel bez doktora.

Chyba.

Predloni jsem zacal novy sport a natrhnul jsem si triceps u lokte. Nejak se to spojilo a pri cvicich na ten loket jsem si zase vyhodil to rameno, nastesti v poloze kdy naskocilo jinym pohybem zpet samo.

Navstivil jsem tedy na doporuceni fyzioterapeutky ortopeda. Prohlasil o mne, ze jsem jak anatomicka pomucka. Trikrat mi sahnul bolestive na ruku a rekl: tak toto je ten triceps, toto mate z luxace ramene, a toto je navic tenisovy loket, delate s pocitacem, ze ? No, normalni lidi kdyz si vyhodi rameno, tak jdou k doktorovi a maji to 3 tydny zafixovane, aby se to mohlo spravne zahojit.

167

Vývoj / Re:GCC optimalizace pro různé ISA

« kdy: 25. 10. 2021, 10:40:45 »

  43:   e9 fc ff ff ff          jmp    44 
         44: R_386_PC32   xxxx

Tohle je tail call. A pokud se pořádně podíváte, tak je i v předchozím ARMovém kódu.

Ano, ja to vim, ale pro sve ucely (viz zacatek diskuse) ho potrebuju zlikvidovat, aby beh koncil opravdu na nejspodnejsi instrukci. Napadlo mne na konec funkce hodit nejaky asm, ktery by tomu zabranil a pak bych si ho automatizovane odstranoval, ale treba je nejaka lepsi cesta.

168

Vývoj / Re:GCC optimalizace pro různé ISA

« kdy: 25. 10. 2021, 09:44:59 »

Volani tech fci jsou fallbacky kdyz neni pristup povolen a neni to cross-page (jsou tam jinak ldr/str), takze bez nich by to zachovat mohl, ale vidite, mozna -Os zauradoval a to mi nedoslo. Zkousel jsem driv jako prvni pokus to napocitat dopredu pri vypoctu ty hodnoty do nejakych promennych bokem, ale to vedlo k uplne stejnemu vysledku, tak nevim kde je chyba. Az vyresim jine problemy, zkusim si s tim jeste pohrat. Prvni kandidat na zlepseni je treba ten zdvojeny write po bytech dole, tim zmizne vic kodu.

Narazil jsem ale i v x86 kodu na dalsi potiz, ktera se bude resit daleko hure nez u toho ARMu:

 3d:   75 09                   jne    48
  3f:   5b                      pop    %ebx
  40:   89 c1                   mov    %eax,%ecx
  42:   5e                      pop    %esi
  43:   e9 fc ff ff ff          jmp    44 
         44: R_386_PC32   xxxx
  48:   5b                      pop    %ebx
  49:   5e                      pop    %esi
  4a:   c3                      ret     

169

Vývoj / Re:GCC optimalizace pro různé ISA

« kdy: 25. 10. 2021, 00:50:11 »

KS: Evidentne programujete 'v jinem svete' nez ja , ty moje rutiny nejsou takhle primocare. Vezmeme tento ARM kod, ktery dela nejakou primitivni operaci s pameti - u toho ale zjistuje pres tabulky jestli ma do pameti pristup (cteni i zapis). Na kodu je videt, ze se tam opakuje vlastne 3x vypocet, ktery gcc neumelo eliminovat, nektere vysledky by sly pouzit opakovane, ale pocitaji se porad znovu. Ten kod je opravdu neoptimalni a hnusny, s tim s bude muset neco udelat. Gcc to dela uplne vsude, x86/x64/arm/aarch64/ppc/riscv/xtensa/... ; JENZE na RISC-V ma tento kod vice nez dvojnasobnou delku na instrukce i delku (nebudu to sem vkladat, je to fakt nuda). Musim vyzkouset jestli primeju gcc pres nejake pomocne promenne ty mezivypocty recyklovat.

Zdrojak sem hodit nemuzu, ma to 3000 radek s hromadou maker a #ifdefu.

Kód: [Vybrat]

   0:	89ba      	ldrh	r2, [r7, #12]
   2:	88f8      	ldrh	r0, [r7, #6]
   4:	8afb      	ldrh	r3, [r7, #22]
   6:	4410      	add	r0, r2
   8:	6a7a      	ldr	r2, [r7, #36]	; 0x24
   a:	b570      	push	{r4, r5, r6, lr}
   c:	b280      	uxth	r0, r0
   e:	eb00 1003 	add.w	r0, r0, r3, lsl #4
  12:	011d      	lsls	r5, r3, #4
  14:	f3c0 3404 	ubfx	r4, r0, #12, #5
  18:	2301      	movs	r3, #1
  1a:	0c41      	lsrs	r1, r0, #17
  1c:	40a3      	lsls	r3, r4
  1e:	f852 2021 	ldr.w	r2, [r2, r1, lsl #2]
  22:	4213      	tst	r3, r2
  24:	d105      	bne.n	32 <rtn11+0x32>
  26:	f3c0 020b 	ubfx	r2, r0, #0, #12
  2a:	f640 73ff 	movw	r3, #4095	; 0xfff
  2e:	429a      	cmp	r2, r3
  30:	d129      	bne.n	86 <rtn11+0x86>
  32:	f7ff fffe 	bl	0 <spec_rdmem_word>
			32: R_ARM_THM_CALL	spec_rdmem_word
  36:	893b      	ldrh	r3, [r7, #8]
  38:	7e39      	ldrb	r1, [r7, #24]
  3a:	88fc      	ldrh	r4, [r7, #6]
  3c:	4419      	add	r1, r3
  3e:	89bb      	ldrh	r3, [r7, #12]
  40:	4408      	add	r0, r1
  42:	6aba      	ldr	r2, [r7, #40]	; 0x28
  44:	441c      	add	r4, r3
  46:	2301      	movs	r3, #1
  48:	b286      	uxth	r6, r0
  4a:	b2c1      	uxtb	r1, r0
  4c:	fa15 f484 	uxtah	r4, r5, r4
  50:	f3c4 3504 	ubfx	r5, r4, #12, #5
  54:	0c60      	lsrs	r0, r4, #17
  56:	40ab      	lsls	r3, r5
  58:	f852 2020 	ldr.w	r2, [r2, r0, lsl #2]
  5c:	4213      	tst	r3, r2
  5e:	d015      	beq.n	8c <rtn11+0x8c>
  60:	4620      	mov	r0, r4
  62:	f7ff fffe 	bl	0 <spec_wrmem>
			62: R_ARM_THM_CALL	spec_wrmem
  66:	1c60      	adds	r0, r4, #1
  68:	6aba      	ldr	r2, [r7, #40]	; 0x28
  6a:	f3c0 3504 	ubfx	r5, r0, #12, #5
  6e:	2301      	movs	r3, #1
  70:	0c44      	lsrs	r4, r0, #17
  72:	40ab      	lsls	r3, r5
  74:	0a31      	lsrs	r1, r6, #8
  76:	f852 2024 	ldr.w	r2, [r2, r4, lsl #2]
  7a:	4213      	tst	r3, r2
  7c:	d009      	beq.n	92 <rtn11+0x92>
  7e:	e8bd 4070 	ldmia.w	sp!, {r4, r5, r6, lr}
  82:	f7ff bffe 	b.w	0 <spec_wrmem>
			82: R_ARM_THM_JUMP24	spec_wrmem
  86:	6afb      	ldr	r3, [r7, #44]	; 0x2c
  88:	5a18      	ldrh	r0, [r3, r0]
  8a:	e7d4      	b.n	36 <rtn11+0x36>
  8c:	6afb      	ldr	r3, [r7, #44]	; 0x2c
  8e:	5519      	strb	r1, [r3, r4]
  90:	e7e9      	b.n	66 <rtn11+0x66>
  92:	6afb      	ldr	r3, [r7, #44]	; 0x2c
  94:	5419      	strb	r1, [r3, r0]
  96:	bd70      	pop	{r4, r5, r6, pc}

170

Vývoj / Re:GCC optimalizace pro různé ISA

« kdy: 24. 10. 2021, 19:13:51 »

RDa: pro RISC neni az tak velky problem napsat ten tool, ktery to reorganizuje. Tim ten koncovy blr/ret/jmp/jb/... vzdy "vypadne", resp. bude se s nim dat snadno pracovat.

KS: Pokud na -Os zpravidla generuje vetsi kod nez na -O2/3, tak je toolchain z meho pohledu rozbity. Vyzkousel jsem to, skutecne je kod mensi, ale stale jsme na cislech, ktera jsou neprijatelna:

   16695 report-rv32-noflags-O2.txt
   16903 report-rv32-noflags-O3.txt  (!pocet instrukci stejny jak -Os, ale je to jen nejaka nahoda, kod se lisi)

Ve vysledku uz je zahrnuta nejaka rucni optimalizace C kodu, kterou jsem v mezidobi udelal, na puvodnim kodu by to bylo horsi.

Pro srovnani, arm a x86 jsou na tom nyni takto:

    8999 report-arm-noflags.txt  thumb2
   10715 report.txt   toto je X86 noflags, pozor nektere instrukce jsou dost dlouhe

Navyseni velikosti kodu o > 70% znamena, ze i kdyz budu mit stejne efektivni CPU, musim mit treba o 70% vice cache, aby byl stejny vysledek u RISC-V. Navic ma rv32 spousti instrukci 32bitovych, proti arm-thumb2, kde jich je radove mene. x86 ma prumer tak 3-4 byty/instr. Je to pro mne celkem zklamani, na to jak tu nekteri aktualni stav teto ISA obhajuji.

171

Vývoj / GCC optimalizace pro různé ISA

« kdy: 23. 10. 2021, 22:47:53 »

Resim aktualne takovy problem, jehoz vystup asi uplne nepotesi priznivce RISC-V ekosystemu (nebo ukaze nejakou moji  neznalost). Pomoci velmi podmineneho prekladu s gcc ( -Os )  vytvarim 'code snippety', ktere nasledne nejaky automat bude skladat za sebe (jde o dynamicky translator). Protoze chci zjistit, jestli to bude pouzitelne i jinde nez v x86 svete, nasbiral jsem ruzne prekladace a zkusil tyto code snippety vygenerovat pro ruzne architektury. Zde je vysledek; pocet vygenerovanych instrukci pro nejakou sadu tech snippetu; cim nizsi, tim kratsi kod. CISC je zde zvyhodnen, protoze instrukce hlavne u x86_64 jsou mnohem delsi nez jinde, hlavne u ARM (thumb2). Co jsem zkoumal vystup, obvykle vic instrukci rovna se i vyrazne mene optimalni kod a zbytecne zonglovani s daty.

Kód: [Vybrat]

  10527 report-arm-noflags.txt  (thumb2)
  10938 report-armv8-noflags.txt
  11209 report-x64-noflags.txt
  12311 report-ppc32-noflags.txt
  12371 report-sparc64-noflags.txt
  12809 report-xtensa-noflags.txt
  13036 report-x86-noflags.txt
  14718 report-mips32-noflags.txt
  16903 report-rv32-noflags.txt
  18407 report-rv64-noflags.txt

Mam jeste jednu sadu, kde se vyhodnocuji nejake operace, to pridava ale do vetsiny snippetu  celkem dost podobneho kodu, ktery by sel resit za pouziti flagu (cf/of/if) kdyby to gcc umelo lepe (typicky pushf a pozdeji v kodu popf pro nasledne snadne zpracovani ruznych overflow/carry/apod.). Spis jen pro priklad vlozim i to:

Kód: [Vybrat]

  13151 report-x64-flags.txt
  13225 report-arm-flags.txt
  15175 report-ppc32-flags.txt
  15535 report-x86-flags.txt
  15770 report-sparc64-flags.txt
  17118 report-xtensa-flags.txt
  22410 report-rv32-flags.txt
  23900 report-rv64-flags.txt

Krome RV64 a mam i realne zelezo, tak mohu porovnat i vysledky v rychlosti, nejak upravene na nejake MHz procesoru (xtensa je ESP32 LX6, tezko srovnavat primo s PowerPC nebo x86 dospelym pocitacem).

Nicmene mam i otazku. GCC mi generuje kod, ve kterem se skace a rutina nekonci nejakym "ret/blr", priklad (ppc32):

Kód: [Vybrat]

   0:	94 21 ff e0 	stwu    r1,-32(r1)
   4:	7c 08 02 a6 	mflr    r0
   8:	90 01 00 24 	stw     r0,36(r1)
   c:	93 e1 00 1c 	stw     r31,28(r1) 
..
  48:	7d 4a 40 39 	and.    r10,r10,r8
  4c:	41 82 00 18 	beq     64
  50:	48 00 00 01 	bl      50 
			50: R_PPC_REL24	spec_read
  54:	7c 7f 1a 14 	add     r3,r31,r3
  58:	98 7d 00 00 	stb     r3,0(r29)
  5c:	39 61 00 20 	addi    r11,r1,32
[b]  60:	48 00 00 00 	b       60 <exec86+0x60>
			60: R_PPC_REL24	_restgpr_31_x   (!!!)[/b]
  64:	81 3d 00 2c 	lwz     r9,44(r29)
  68:	7c 69 18 ae 	lbzx    r3,r9,r3
[b]  6c:	4b ff ff e8 	b       54 [/b]

Na adrese 60 je netypicke ukonceni (dusledek -Os), kazdopadne i kdyby tam bylo blr, nekonci tim rutina. Ja bych potreboval, abych z konce rutiny (0x6c) mohl jen odriznout blr a nebyl tam nejaky odskok "nahoru". A tim by slo trivialne retezit snippety za sebe v dynamicky generovanem kodu. Tusite jak k necemu takovemu primet gcc? Nedela to jen na powerpc, ale i jinych architekturach, typicky ARM. Reseni by bylo "linearizovat" kod, aby sel odshora dolu, a neskakal si nekam vzhuru. Jenze to musim naprogramovat. Dale bych uvital, kdybych nejak prekladaci umel rici, aby se treba vyvaroval nejakeho konstruktu, treba nejake relokaci, apod. Diky za pripadne tipy.

Prekvapenim je RISC-V, ktery ciselne, ale i pohledove generuje pomerne sileny kod. Tam, kde ma ARM uz spocitano, se risc-v potaci nekde v tom jak vidlemi prehazovat data... registru ma pritom mnohem vic RISC-V.

172

Hardware / Re:ESP32 MMU/MPU

« kdy: 18. 10. 2021, 18:33:57 »

Do "TRM" jsem koukal. Ja tam tech nejasnosti vidim celou radu, popravde jich je spis vic nez tech jasnych veci .

173

Hardware / ESP32 MMU/MPU

« kdy: 18. 10. 2021, 17:19:54 »

Potreboval bych na ESP32 SoC v zakladni verzi (LX6), pripadne -S2 (LX7) a -C3 (Risc-V) udelat detekci zapisu do nekolika stranek (pametovych rozsahu). Jsem obeznamen s tim, jak funguje ARM MPU, Tensilica/Cadence LX6/LX7 by mely mit neco podobneho. V datasheetu je to nejak popsane, ale moc moudry z toho nejsem. RISC-V by taky neco mel mit, ale opet me zkusenosti jsou nulove. A navic si nejsem jist jak je to u toho ESP, protoze na foru pisou ze "neni otestovano"...

Tusite tu nekdo jak se LX6/7 MMU(MPU) da pouzit na detekci toho zapisu? Predstava je, ze budu mit pro N stranek definovane radky v MPU, ktere povoli cteni, ale faultnou pri zapisu. Ve fault handleru pak udelam pres tyto data invalidate a povolim zapis.

A jeste navic ... potrebuju aby to u ESP32-WROVER chodilo nad externi PSRAM . To uz jsem z datasheetu nevycetl vubec, jestli je takhle mozne.

174

Vývoj / Re:FPGA s Verilog na PCIe kartě

« kdy: 16. 10. 2021, 19:39:33 »

Předně, FPGA mě láká už dlouho, ale VHDL je moc lowlevel. Oproti tomu jazyky jako Scala/SystemVerilog

Na zacatku pisete Verilog, ted SystemVerilog. Nicmene, VHDL vs Verilog - oba popisuji to same, je to myslim dost podobne srovnani C vs Pascal nekdy v 90. letech (tehdy byl Turbo Pascal moda na skolach). Alespon tak to vidim ja.

My 2 cents:

Podle me to je uplne jedno v cem ty FPGAcka programujete, dabel je nekde uplne jinde, nezavisly na popisnem jazyku.

Koupil bych si ten nejlevnejsi kit s nejakym pidi FPGA co nekde najdete a vyzkousel do nej neco naprogramovat. Nez "vyrostete" do nejakeho vetsiho FPGA, mate moznost se naucit spoustu veci, a zjistit, jak se to doopravdy ma.

Nebo se na opencores mrknete jak veci navrhuji jini lide, pro predstavu o slozitosti a na jake problemy se narazi to staci.

175

Vývoj / Re:FPGA s Verilog na PCIe kartě

« kdy: 15. 10. 2021, 01:10:42 »

Chtelo by to asi vedet vic informaci o tom co vlastne chcete delat. Kdybych to delal ja ... a ze nevim "co bych delal", moji snahou by bylo eliminovat ty drahe prvky, treba tim, ze bych se snazil vyhnout pouziti nejake DDR okolo, a nejak to jen prohnal predkousane tim FPGAckem. Vsechno je pak o dost jednodussi. A idealne treba tak, ze bych to napojil primo na nejakou ARM desticku, cimz bych se vyhnul problemum s PCIe nebo pomalosti USB. MediaTek ma SoC s periferiemi, ktere jsou takovy svycarsky nozik na komunikaci (slouzi to treba na vystup LCD/HDMI/... ale presvedcite to k temer cemukoliv).

Alternativne nejake vetsi FPGA s hard ARM core, nicmene s tim mam nulove zkusenosti, nikdy jsem s tim nedelal. https://www.xilinx.com/products/silicon-devices/soc/zynq-7000.html

176

Vývoj / Re:FPGA s Verilog na PCIe kartě

« kdy: 14. 10. 2021, 20:25:32 »

Ja jsem takovy lepic lowcost reseni, neznam danou ulohu, atd. Nebylo by resenim nejake levnejsi FPGA a pres nejaky cypress to krmit daty z USBcka ? A tech zarizeni mit diky nizsi cene vic, aby to dalo pozadovanou rychlost zpracovani.

177

Hardware / Re:Zabezpečení kabelu proti ukradení

« kdy: 12. 10. 2021, 19:09:13 »

Nechci tu delat flamewar, prijde mi to celkem usmevne, i kdyz chapu, ze lide jsou velmi ruzni. Celkem mne prekvapila cena tech cable locking mechanismu, jestli to ma fakt smysl takhle resit.

V jinem oboru se problem "uzamceni" resi hodne dobre utazenym sroubem. Mozna by stalo za to oslovit nejakou zamecnickou dilnu, aby navyrabeli nejake uchyty, budou to desetikorunove polozky. Vyresi to problem se nepripravenym zlodejem. Nezastavi to toho kdo se na kradez pripravi a vezme si naradi.

Mozna by bylo i jine reseni, vytisknout si neco na 3D tiskarne a odolnost proti vandalovi zvysit treba vlozenim nejakeho silnejsiho dratu. Vyhoda je temer nulova cena a adaptovatelnost na ruzne podminky. Resil jsem plastove "sroubky", funguje to celkem dobre, na zpevneni bych mozna dovnitr strcil diru, do ktere se nasroubuje nejaky maly metricky sroub (pak ten plastovy uz neutrhnete).

178

Vývoj / Re:ESP IDF prerušovanie Wifi pripojenia.

« kdy: 23. 09. 2021, 23:22:44 »

A kdyz vezmete nejaky bezny example z esp-idf, bezi to jak ma?

Popravde receno nechapu duvod proc se odchylovat od toho co Espressif vypotil, ale asi k tomu mate nejaky duvod.

Ne ze bych mel pocit, ze veci okolo ESP jsou naprogramovany dobre, ale ten bezny zaklad mi nikdy vylozene nepadal, casto se akorat stava, ze zarizeni najednou neni dostupne a v logu neni nic smysluplneho.

179

Vývoj / Re:Geolokace, idealne zdarma

« kdy: 12. 09. 2021, 15:08:45 »

S Google byl problem, ze nerikal jak moc presne je umisteni, resp. asi to nerika stale. Prosel jsem si ziskanim API klice (to jsem mohl udelat uz prvne) a ne prilis validni adresy stejne skonci 'APPROXIMATE'. Treba u transkripce do latinky. Kolize jsou uplny problem.

Idealni by bylo vratit treba vice moznosti s nejakymi pravdepodobnostmi-ale to chci asi moc :-(. Mozna je reseni prozkouset jen urcite subsety udaju, aby to vyhodilo treba mesto, nebo opacne. A najit nejpravdepodobnejsi vysledek podle mnozstvi matchnutych udaju pouzit.

180

Vývoj / Geolokace ideálně zdarma

« kdy: 12. 09. 2021, 12:41:01 »

Potreboval bych sluzbu, ktere se posle adresa kdekoliv na svete a sluzba vrati idealne zpet "opravenou" adresu v nejake normalizovane podobe (ulice, cislo, ...), zem, ... a informace k tomu jak presna adresa je (pripadne muze dat i GPS souradnice, ale ty nepotrebuju).

Jde o to, ze potrebuju validovat adresy, aby z toho vypadlo treba kdyz nekdo zada misto polska zemi USA, aby to naslo spravne "Polsko".

Idelani by bylo nejake free api, ktere je treba omezene, tech adres neni moc za den, abych nemusel resit nejake subscription.  nominatim.openstreetmap.org znam, jeho problem je kdyz je zadan kus adresy spatne (napr. USA misto Poland, pripadne v adrese jsou nejake nesmysly typu adresat USA ale ve zbytku adresy je !!! POLAND !!! :-) ), to by mozna slo resit tak, ze bych vyzkousel jednotlive casti vyhazovat - pokud je spatne jen jeden udaj tak by se to mohlo na jednu adresu chytit. Neresi to ale problem preklepu/jineho zapisu nez znaji OSM. Google geolocation to pritom umi docela slusne.

Nebo .. ?