Jump to content

Assemblers


Jacob
 Share

Recommended Posts

AndrisBB

Tak visi tie bithaki aizņems pat vairāk instrukcijas kā vienkārš modulo

 

int isEven(int num) {
    return num % 2 == 0;
}

kompilējas uz:

isEven:
  eor r0, r0, #1
  and r0, r0, #1
  bx lr

Tās bitu operācijas aizņems vairākas instrukcijas, tātad būs lēnāk jeb kautkāda XOR, OR utt gadījumā. kautgan tu jau tāpat redzi ka viņš vienkārši izmanto AND.

 

 

Link to comment
Share on other sites

Anonīms Alkoholiķis

Tagad paskaidro, kapec tavs nokompiletais kods ir apaudzis ar nevajadzigiem mesliem un par 50% lielaks neka nepieciesams?

 

int isEven(int num) {
    return num & 1;
}

 

kas kompilejas ka

isEven:
        and     r0, r0, #1
        bx      lr

Labots - Anonīms Alkoholiķis
Link to comment
Share on other sites

Raimonds1

Nu, mēs jau nezinām, vai tie ir no klaviatūras ievadīti cipari vai arī varbūt tā ir datu plūsma no sensora vai arī meklē kaut kādā datu bāzē vai sarakstā kādus numurus vai kaut ko apzīmējošus skaitļus. Tāpat nav jau zināms, vai to apstrādās kaut kāds  Arduino Gudrās Mājas modulis, datora, planšetes vai telefona 1,2,4 kodolu procesors.

 

Tāpēc vienā gadījumā prastākais būs tie visi bithacks, citā varbūt pat ASCII kodu tabula un citā dalīšana ar 2 vai pēdējā cipara pāris-nepāris vai binārā koda 1 bita 0 vai 1 noteikšana.

 

Pie tam to kopainu vēl ietekmēs kompilators, kas vienai iekārtai no kaut kāda if else, dalīšanas ar 2 vai 1 baita noteikšanas saģenerēs vieniem dzelžiem maksimāli tuvu kodu un citiem pamanīsies aizņemt desmit un vairāk ciklus un vēl izmantos papildu atmiņas resursus.

 

 

Ja tā ir klaviatūra, pēdējais cipars pirms enter vai rindas pārneses vai kā cita. Tāds piemērs. Programma nosaka, ka vispār ievada ciparu - Y/N. Atceras pēdējo. Ja ciparu ievadi pārtrauc un spiež citu noteiktu taustiņu, izvada rezultātu - true/false.

 

Labots - Raimonds1
Link to comment
Share on other sites

Anonīms Alkoholiķis

Man skiet, ka sita diskusija ir jaturpina reddita.. https://www.reddit.com/r/codegolf/ vai stackexchange https://codegolf.stackexchange.com/

 

Tur varesiet turpinat rullet savu asamblera gurki pret visadam ezoteriskam valodam un citiem baklazaniem.

 

Labots - Anonīms Alkoholiķis
Link to comment
Share on other sites

AndrisBB
Pirms 42 minūtēm , Anonīms Alkoholiķis teica:

nevajadzigiem mesliem un par 50% lielaks neka nepieciesams?

 

Tas tak vienkārši piemērs un papildus instrukcija ir lai atgrieztu rezultātu no funkcijas. 

Ja nevajag funkciju, tad neliec funkcijā, vai uztaisi funkciju inline, tad nebūs tev tās papildus rindas. Uz x86 tur pat 2 papildus rindas, jeb instrukcijas :)

Labots - AndrisBB
Link to comment
Share on other sites

HIGH-Zen

Savā laikā sāku ar wasm.ru un krekošanu.

Citēt

#1. Однажды студент по имени Дениска Ричи сел изучать абсолютно новый для него язык программирования. Первое, что он сделал - написал программу "Hello, World", и, что самое удивительное, она у него заработала. Когда же он перелистнул следующую страницу своей умной книжки, то ни черта не понял. То есть задним умом своей головы он, конечно же, понимал, что большинство известных ему программ умеют намного больше, чем тупо приветствовать мир, однако понять, каким это извращенным образом такие здоровские штуки можно запрограммировать, он не мог.

 

Link to comment
Share on other sites

  

pirms 6 stundām , usver teica:

ja parametrs ir int, tad pat nekompilēsies // piekasīšanās:)

hmm... kāpēc ne?

 

pirms 3 stundām , AndrisBB teica:

Tak visi tie bithaki aizņems pat vairāk instrukcijas kā vienkārš modulo

Štrunts par instrukcijām, mani vairāk interesē, cik ciklus viss tas blāķis patērēs :D

 

pirms 3 stundām , Anonīms Alkoholiķis teica:

Tagad paskaidro, kapec tavs nokompiletais kods ir apaudzis ar nevajadzigiem mesliem un par 50% lielaks neka nepieciesams?

Q: Vai 5 ir pāra skaitlis?

A: 5 (00000101) & 1 = 1, hmm, jā, 5 ir pāra skaitlis

 

Citiem vārdiem sakot - tas tavējais "num & 1" nedos atbildi uz "is even".

 

 

Labots - binary
Link to comment
Share on other sites

binary, tas ir char - viņu var interpretēt kā int, bet jautājums, vai nevajag kāstot. Upd: Notestēju - g++ pieņēma bez pretenzijām bez kāstošanas. Java IMO kāstu vajadzētu.

Link to comment
Share on other sites

Es pat nestādos priekšā, kādus flagus būtu jāpiemet, lai kompilators kaut ieminētos par ko tādu. Ar -Wall -Wextra -pedantic kompilators to kodu sagremo bez problēmām. Un pareizi jau it kā ir. Būtu otrādi (padotu int funkcijai, kura sagaida char), tad gan būtu jābļauj.

 

To piebildi (the "usage" section does not guarantee that isEven('2')  actually returns true) gan es šobrīd atsakos saprast. Lai gan … tajos ifos jau līdz '2' nemaz nav uzskaitīts (vismaz screenshotā) :D 

Labots - binary
Link to comment
Share on other sites

AndrisBB
Pirms 51 minūtēm , binary teica:

an es šobrīd atsakos saprast.

Ko tu tur gribi saprast? Tas tak JavaScript, tur reizēm loģikas nav :D

 

1 stundu atpakaļ, binary teica:

Štrunts par instrukcijām, mani vairāk interesē, cik ciklus viss tas blāķis patērēs

A kas to lai zin. Uz moderna ARM mikrokontroliera viņš prefetcho instrukcijas vairākas uz priekšu. Piemēram ja ir kautkāds if/else, tad abus varintus sāks izpildīt paralēli (branch prediction), tad atmetīs to kurš izrādijās nepareizs.

Plus vēl ļoti atkarīgs no kādas atmiņas ielādēs instrukcijas, varbūt tas kods ir iekš TCM (Tightly-Coupled Memory) kur CPU var viņu dabūt uzreiz, a varbūt kautkur flashā, kur vajadzēs daudz ciklus, lai dabūtu, varbūt tas viss ir kešā un notiks kautkur pa vidam. 

Neatceros, bet uz ARM laikam tā nav, bet dažādas instrukcijas aizņem dažādu ciklu skaitu.

 

Reku čalis mēģina izrēķināt cik ciklus aizņem viena instrukcija :D

https://community.arm.com/developer/ip-products/processors/f/cortex-m-forum/12005/measuring-cortex-m4-instruction-clock-cycle-counts

Labots - AndrisBB
  • Patīk 1
Link to comment
Share on other sites

Mezavecis

Katram sava pieredze. Asambleri esmu redzējis, kā džeki kodē, bet taustījis neesmu un neizjūtu vēlmi to darīt. Ar iekārtām darbs ir daudzus gadus, bet vairāk par C++ nav vajadzējis zināt, kuru ikdienā arī nevajag, jo firmwares nerakstu. Kad jauns uz zaļš, tad var taustīties, lai atrastu savu nišu, pēc tam jau šī taustīšanās saistīta ar konkrētām vēlmēm, vajadzībām.

 

pirms 5 stundām , Raimonds1 teica:

Padomāju un izdomāju, kas tas if else piemērs ir vēl prastāk risināms

Bija tāds biedrs Diegs un arī veselu megatopiku par to izcepa. Joprojām nesaprotu jēgu. Tāpat kā šeit - tukša laika nosišana un galvas piebāšanas ar teorētiskiem mēsliem, kam praktiskās jēgas nav.

 

Link to comment
Share on other sites

Pirms 16 minūtēm , AndrisBB teica:

Ko tu tur gribi saprast? Tas tak JavaScript, tur reizēm loģikas nav :D

Rādās, ka katrs tur saskata citu valodu.

 

Starp citu, savulaik dabūju "daily WTF" no šāda rezultāta (sorry, ka neiet kopā ar topika tēmu, bet nu ir no sērijas "saprast, kā tas strādā"):

>>> False == False in [False]
True

 

  • Haha 1
Link to comment
Share on other sites

Raimonds1
1 stundu atpakaļ, Mezavecis teica:

Katram sava pieredze. Asambleri esmu redzējis, kā džeki kodē, bet taustījis neesmu un neizjūtu vēlmi to darīt. Ar iekārtām darbs ir daudzus gadus, bet vairāk par C++ nav vajadzējis zināt, kuru ikdienā arī nevajag, jo firmwares nerakstu. Kad jauns uz zaļš, tad var taustīties, lai atrastu savu nišu, pēc tam jau šī taustīšanās saistīta ar konkrētām vēlmēm, vajadzībām.

 

Bija tāds biedrs Diegs un arī veselu megatopiku par to izcepa. Joprojām nesaprotu jēgu. Tāpat kā šeit - tukša laika nosišana un galvas piebāšanas ar teorētiskiem mēsliem, kam praktiskās jēgas nav.

 

 

Ja programma ir tās 

else if (number ==2) return true;

else if (number ==3) return false;

else if (number ==4) return true;

else if (number ==5) return false;   rindas, tad kaut kur tie binārie skaitļi ir jāglabā, jāvelk ārā no atmiņas un jāsalīdzina ar aktuālo ievadīto, no kaut kāda sensora vai slēdžu kombinācijas saņemto vai no datu blāķa ielasīto bināro skaitli.

 

Savukārt, ja salīdzina tikai vienu bitu, tad tur ir pavisam cits process.

Un, protams, vēl ir jautājums, kas un kā programmēja kompilatoru.

  • Haha 1
Link to comment
Share on other sites

Raimonds1

Un vēl - tās if else rindiņas ir ļoti viegli lasāmas, saprotamas un uzreiz skaidrs, kas tur ir jāpanāk.

Tie citi risinājumi tādi var nebūt, tur kāds aizmirsīs ierakstīt pēc// ko te meklē un būs jāzīlē.

  • Haha 1
Link to comment
Share on other sites

marrtins
pirms 3 stundām , AndrisBB teica:

A kas to lai zin. Uz moderna ARM mikrokontroliera viņš prefetcho instrukcijas vairākas uz priekšu. Piemēram ja ir kautkāds if/else, tad abus varintus sāks izpildīt paralēli (branch prediction)

Uz x86 jau arī (sen) ir šis branch prediction, tikai nekas netiek izpildīts, bet tikai pre-fetchots. Var iegūt nesliktu peformanci, ja paņem pareizo branch, bet visai lielais auzas, ja tas kods branchojas bezjēgā daudz un/vai CPU nespēj "paredzēt" pareizo branch. Mjā, valodiņa panesās...

Link to comment
Share on other sites

Inspektors Caps

Jaudīgi superskalāri procesori var ne tikai prefetch-ot bet arī izpildīt, jo tiem ir arī vairāki ALU un citi bloki. To sauc par speculative execution. Tādi procesori ir visi x86 kopš pirmā Intel Pentium, visa ARM Cortex-A sērija un nu jau ar Cortex-M7 (un topošo Cortex-M55) tas ir ienācis pat mikrokontrolieru pasaulē. Starpcitu, pēc IPC Cortex-M7 ir salīdzināms ar pirmajiem Atom, kamēr Cortex-A7x jau ir jaudīgu x86 desktop CPU līmenī arī pēc absolūtajiem MIPS rādītājiem. Vai vispār zināt, ka mūsdienu jaudīgākie desktop procesori spēj sasniegt pat līdz 11 IPC? 11 paralēlas instrukcijas uz takti! Tagad padomājiet kādu titānisku inženieru pūliņu dēļ jūsu Electron un citu websūdu bāzētās hipsteru ne-do-aplikāciju parodijas vispār spēj pakustēties. Un tad padomājiet kā tās lidotu, tērējot 20x mazāk elektrības un strādātu 20x ilgāk, ja tās nebūtu veidotas no mēsliem...

 

pirms 19 stundām , Jacob teica:

mani secinājumi ir tādi, ka programmētājam tomēr der aptaustīt assembleri. Ne jau praktiskā pielietojuma dēļ, bet gan saprašanas par to, kā viss darbojas dēļ

Ja programmēsi high-level lietas, tad tieši tā arī ir. Ja programmēsi low-level un īpaši embedded, tad klāt nāk arī tas, ka šur tur tomēr ir jāuzraksta kādas specifiskas funkcijas un citi nelieli koda gabali asamblerā, vai kādas rindas ar inline assambler.

Labots - Inspektors Caps
  • Atbalstu 2
Link to comment
Share on other sites

11 minutes ago, Inspektors Caps said:

Ja programmēsi high-level lietas, tad tieši tā arī ir. Ja programmēsi low-level un īpaši embedded, tad klāt nāk arī tas, ka šur tur tomēr ir jāuzraksta kādas specifiskas funkcijas un citi nelieli koda gabali asamblerā, vai kādas rindas ar inline assambler.

 

Tātad jebkurā gadījumā programmētājam ir jāzina vismaz nedaudz assembleris. Paldies!

Link to comment
Share on other sites

Inspektors Caps
2020.07.31. , 02:41, M_J teica:

Mani kaitina, ka bremzē citi, ne manējie, kontrolieri nevaru vien sagaidīt atbildi, nesaprotu, ko viņi tur čammājas. Zinot, ka assemblerī programmē vairs tikai retais, un redzot šīs problēmas, kas saistītas ar acīmredzami ne-assemblerī programmētiem kontrolieriem, negribot uzprasās jautājums par minēto problēmu un programmēšanas vides korelāciju.

Vainot tajā C ir aplami. C nav nekāda Java ar garbage collector un hvz vēl ko. Ja iemesli ir sociāla tipa, tad tas ir vispārīgās rietumu sabiedrības degradācijas dēļ. Ja iemesli ir tehniski, tad iespējams, ka tai ierīcei ir vēl kādi augstākas prioritātes uzdevumi un atbilde komunikācijas līnijā var nedaudz pagaidīt. Protams, ir liela varbūtība, ka tāda gaidīšana vispār notiek tikai tādēļ, ka ir lameriska firmware arhitektūra Arduino trulā superloop stilā. Vēl līksofti arī tipiski nodarbojas ar polling, jo to izstrādātāji ir par stulbu, lai korekti realizētu interrupt=>event=>task principus.

 

2020.07.31. , 02:41, M_J teica:

Skatos uz C kodu - maksimāli vienkāršs, neredzu, kur ko varētu izdarīt optimālāk. Pārliku assemblerī no C valodas 1:1 visas tās darbības ar reģistru bīdīšanām xor-iem un citām darbībām, kas nu tur ir. Un redzu, ka tur ir liekas darbības, ka assemblerī to pašu, izmantojot kontroliera arhitektūras īpatnības, to, kā tiek izpildīta katra komanda, kādi karogi pie katras komandas tiek uzmesti un citas nianses, var izdarīt racionālāk.

Kāds kompilators un optimizācijas līmenis? Izklausās, ka esi skatījies kādu GCC piemēram -O0 kompilētu kodu, kam nav mērķis būt optimālam, bet gan ērti debugojamam. Turpretī, sākot ar -O2, jau parasti ir manāms tieši pretējais - kompilators izmanto arhitektūras un konkrētā kodola īpatnības, pat ņemot vērā instrukciju secības, pipeline, bus width, kešatmiņas (ja tāda ir) un tādas nianses. Un tad vēl visam pa virsu nāk tas, ka vienu un to pašu kodu vienā projektā varu kompilēt maksimālai ātrdarbībai, bet otrā minimālam izmēram. Piemēram, bootloader projektiem ātrdarbība bieži nav svarīga, bet izmērs gan ir.

 

2020.07.31. , 02:41, M_J teica:

Daudzi kontrolieri, to dara dzelžu līmeni. Bet tādā gadījumā - ja CAN paketē kaut kas nav kārtībā, kontrolieris to paketi "neredz". Jā, protams, ir visādi kļūdu karogi reģistros un tādā garā, bet, lai atrastu problēmu, man vislabāk tad patīk izķidāt to paketi pa bitiem, izmantojot jau minētos taimerus un interruptus. ... Paliek vairāk laika katra bita izķidāšanai, varu precīzi izsekot, kā atšķirīgu kvarca frekvenču dēļ "aizpeld" bitu "frontes" un, piefiksēt kurā momentā nojūk sinhronizācija.

Kādēļ dzelžu problēmas nerisini ar piemēram lēto Siglent SDS1202X-E, kas pat analizē CAN, kādu citu osciloskopu vai loģisko analizatoru? Tad Tu taisi CAN ar bit-bang? Izklausās pēc velosipēda izgudrošanas... Gala produktā tāpat no paketes, kurai nesakrīt kontrolsumma, nav nekādas jēgas. Tā ir bojāta, neviens tās bits nav uzticams un tā ir jāizmet. Vienīgais, kam tad ir jēga, ir skaitīt izkropļotās paketes priekš statistikas vai citiem mēriem, kam tad arī ir paredzēti attiecīgie karogi reģistros.

Link to comment
Share on other sites

pirms 3 stundām , Inspektors Caps teica:

Vainot tajā C ir aplami. C nav nekāda Java ar garbage collector un hvz vēl ko. Ja iemesli ir sociāla tipa, tad tas ir vispārīgās rietumu sabiedrības degradācijas dēļ. Ja iemesli ir tehniski, tad iespējams, ka tai ierīcei ir vēl kādi augstākas prioritātes uzdevumi un atbilde komunikācijas līnijā var nedaudz pagaidīt. Protams, ir liela varbūtība, ka tāda gaidīšana vispār notiek tikai tādēļ, ka ir lameriska firmware arhitektūra Arduino trulā superloop stilā. Vēl līksofti arī tipiski nodarbojas ar polling, jo to izstrādātāji ir par stulbu, lai korekti realizētu interrupt=>event=>task principus.

Piekrītu. Noteikti arī C visu var izdarīt. Bet nedara. Personīgi zinu vairākus cilvēkus, kas ņemas iekš Arduino un ne par taimeriem, ne pārtraukumiem, ne vispār par to, kas kontrolierī darās dzelžu līmenī, negrib pat dzirdēt. Ja programmē ASMā tad nezināt kontroliera arhitektūras pamatus ir neiespējami.

 

pirms 4 stundām , Inspektors Caps teica:

Kāds kompilators un optimizācijas līmenis?

nekompilēju ne ar kādu kompilatoru, mehāaniski pārliku assemblerī
ko kompilators izdotu, nezinu
 

;Katru reizi, kad nāk klāt jauns bits, tiek pārrēķināta kontrolsumma
;man tas tiek darīts pārtraukumā

;internetā atrastais kods ir šads:

void
CalcCRC( WORD * CRC_rg, WORD CRC_NextBit ) {
WORD CRC_Next;
      CRC_Next = CRC_NextBit ^ ((*CRC_rg >> 14) & 1);
      (*CRC_rg) <<= 1;
      if (CRC_Next == 1) {
            (*CRC_rg) = (*CRC_rg ^ 0x4599) & 0x7fff;
      }
      CRC_Count++;
}


;iepriekš uzkrātā kontrolsumma reģistros XH:XL
;crc bitu skaitītājs reģistrā r6
;jaunpienākušais bits ir nulltais bits reģistrā r18

;pirmajā tuvinājumā sanāk šadi:

CRC_Next = CRC_NextBit ^ ((*CRC_rg >> 14) & 1);

;šo rindiņu burtiski pārliekot assemblerī sanāk šādi

	movw	ZH:ZL,XH:XL
	ldi	r16,14
c1:
	lsr	ZH
	ror	ZL
	dec	r16
	brne	c1
	eor	ZL,r18
	andi	ZL,1

(*CRC_rg) <<= 1;

;šī rindiņa assemblerī varētu izskatīties šādi
	lsl	XL
	rol	XH
	
;šī konstrukcija assemblerī varētu izskatīties šādi

if (CRC_Next == 1) {
	(*CRC_rg) = (*CRC_rg ^ 0x4599) & 0x7fff;
}
 
	cpi	ZL,1
	brne	c2
	ldi	ZL,0x99
	ldi	ZH,0x45
	eor	XL,ZL
	eor	XH,ZH
	andi	XH,0b01111111
c2:

CRC_Count++;
	
	inc	r6
	ret

;uzreiz redzams, ka bīdīt 14 pozīcijas, lai tikai noskaidrotu viena bita statusu ir pilnīgi bezjēdzīgi
;turklāt kontrolsumma jebkurā gadījumā jābīda vienu pozīciju pa kreisi, un interesējošais bits nonāks vecākajā pozīcijā
;kas nozīmē, ja bits būs uzmests, tad skaitlis būs negatīvs
;pēc pirmās optimizācijas rezultāts sanāk šāds:

cr15:
	inc	r6
	ldi	ZL,0x99
	ldi	ZH,0x45
	lsl	XL
	rol	XH
	brmi	cr15m	;vai vecaakais bits uzmests?
;vecaakais bits nav uzmests
	sbrs	r18,0	;vai biti sakriit?
	ret		;ja sakriit, nekas nav jaadara
	eor	XL,ZL
	eor	XH,ZH
	ret
;vecaakais bits uzmests
cr15m:
	sbrc	r18,0	;vai biti sakriit?
	ret		;ja sakriit, nekas nav jaadara
	eor	XL,ZL
	eor	XH,ZH
	andi	XH,0b01111111
	ret

;tā kā apakšprogramma tiek realizēta pārtraukumā, tas nozīmē, ka visi izmantotie reģistri 
;sākumā būs jāsabāž stekā, bet pēc tam no turienes jāizvelk tas aizņems lērumu laika
;lai tas nebūtu jādara, pieņēmu lēmumu dažus reģistrus izmantot tikai un vienīgi kontrolsummas rēķināšanai
;un nekur citur neizmantot
;tātad jau reģistros r14 un r15 visu laiku glabāsies vērtības 0x99 un 0x45
;kontrolsummu rēķināsim reģistros r23:r12
;pārējais, kā iepriekš

;jaareekina CRC15
	inc	r6
	lsl	r12
	rol	r23
	brmi	ocs1	; vai vecaakais bits uzmests?
;vecaakais bits nav uzmests
	sbrs	r18,0	;vai biti sakriit?
	ret		
	eor	r12,r14
	eor	r23,r15
	ret
;vecaakais bits uzmests
ocs1:
	sbrc	r18,0	;vai biti sakriit?
	ret		;ja sakriit, nekas nav jaadara
	eor	r12,r14
	eor	r23,r15
	andi	r23,0b01111111 ;patiesiibaa sis ir lieki, jo CRC 15 vecaakais bits muus neinteresee
	ret

salīdzinājumā ar sākotnējo variantu ietaupījums ir. Interesanti ko dotu kompilators, turklāt nezinu, neesmu pētījis, kā pateikt kompilatoram konkrētus reģistrus nekur citur programmā neizmantot.

 

pirms 4 stundām , Inspektors Caps teica:

Kādēļ dzelžu problēmas nerisini ar piemēram lēto Siglent SDS1202X-E, kas pat analizē CAN, kādu citu osciloskopu vai loģisko analizatoru? Tad Tu taisi CAN ar bit-bang? Izklausās pēc velosipēda izgudrošanas... Gala produktā tāpat no paketes, kurai nesakrīt kontrolsumma, nav nekādas jēgas. Tā ir bojāta, neviens tās bits nav uzticams un tā ir jāizmet. Vienīgais, kam tad ir jēga, ir skaitīt izkropļotās paketes priekš statistikas vai citiem mēriem, kam tad arī ir paredzēti attiecīgie karogi reģistros.

  'Jā, uztaisīju CAN ar bit-bang. Jā, ir velosipēda izgudrošana, toties tagad zinu CAN paketē katru bitu. Tāpēc esmu sajūsmā par Andra paštaisīto procesoru. Lai kaut ko darītu ar sajēgu, ir jāzina vismaz vienu līmeni dziļāk, par to, kurā strādā, un Andris ir ielīdis baigi dziļi. Un tā pakete jau nebija nepareiza, vienkārši atšķirīgu kvarcu dēļ uztvērēja un raidītāja ātrumi atšķīrās par dažiem procentiem, pirmajā piegājienā negāja nekas, un vajadzēja izpētīt, kā darbojas tas dzelziskais resinhronizācijas mehānisms.

  • Patīk 1
Link to comment
Share on other sites

AndrisBB

Nav gan skaidrs kāda mārutka pēc jātaisa CAN busa bit-bang un pašam CRC jārēķina, tam visam it domāti dzelži. Vaitad mikrokontrolieru ar CAN busu trūkst?

Skaidrs ka ir cilvēki kas brīvajā laikā Sudoku rēķina kā izklaidi, bet ja to visu dara darbralaikā, tad diezko jēdzīgi neizklausās un maz ticams ka kāds par to maksās. Darīšana darīšanas pēc.

 

Plus būtu vismaz uzrakstijis kas tas par mikrokontrolieri, savādāk te nevienam nav ne jausmas kādu ASM tu te posto.

Labots - AndrisBB
Link to comment
Share on other sites

Just now, AndrisBB teica:

Nav gan skaidrs kāda mārutka pēc jātaisa CAN busa bit-bang

Tāda paša mārrutka pēc, kāpēc jātaisa pašam savu CPU. Man tas sagādā prieku un gandarījumu. Nevis paņemt gatavu dzelzi, un izmantot gatavus risinājumus, bet izpētīt visas nianses un uztaisīt pašam no nulles. Ko lai dara, ja maksā daudzos gadījumos tieši par lietām, kas galīgi neliekas interesantas. Bet par to, ka daru to darba laikā - labi, ka pats esmu sev darba devējs. 

Link to comment
Share on other sites

AndrisBB

CPU tika kā jau minēts taisīts, tapēc ka bija jātaisa, jeb to var nosaukt par mājasdrabu.

Jebkurā gadījumā izklausās tik sīka problēma, ka vispār nav vērts par to domāt. Maz ticams ka tavas iekārtas viss mērkis ir kalkulēt CRC.

 

Link to comment
Share on other sites

AndrisBB

Nu vienā no citiem moduļiem mums ja ne gluži bij jātaisa pilnu OS, tad jāuzlabo esošo. Bij tur speciāla "mācību" OS, kurai trūka viskautkā, vai tas būtu kāds syscall, vai scheduler diezgan dranķigs. Tad katrs varēja izvēlēties savu lietu un to uzlabot, vai pievienot, ja tādas nebij vispār.

Kadu laiku pirs manis kursā bij viens čalis, kurš izveidoja FreeRTOS, tagad tas ir faktiski industrijas standarts un viena no populārākajām OS priekš mikrokontroliera.

Es ar viņu visur izmantoju, tagad gan vairāk sāk patik Zephyr, bet tā mazliet lielāka, kautkas pa vidam starp FreeRTOS un minimālistisku Linux.

Link to comment
Share on other sites

Ko lai dara, ka skolas laikā tādas lietas nekādi nebija iespējamas. Jāmācās tagad.


Just now, AndrisBB teica:

Jebkurā gadījumā izklausās tik sīka problēma, ka vispār nav vērts par to domāt.

Tā sīkā problēma finansiāli nemaz nav tik sīka, sākotnēji abu kontrolieru nesarunāšanās tika risināta sarunās ar abiem ražotājiem, diemžēl bez rezultātiem.

Link to comment
Share on other sites

Raimonds1
pirms 15 stundām , Inspektors Caps teica:

Jaudīgi superskalāri procesori var ne tikai prefetch-ot bet arī izpildīt, jo tiem ir arī vairāki ALU un citi bloki. 

.............................

Ja programmēsi high-level lietas, tad tieši tā arī ir. Ja programmēsi low-level un īpaši embedded, tad klāt nāk arī tas, ka šur tur tomēr ir jāuzraksta kādas specifiskas funkcijas un citi nelieli koda gabali asamblerā, vai kādas rindas ar inline assambler.

 

Un te tieši parādās loģiskā vajadzība pēc Bunža grāmatas, jo te nu ir tā loģiskā pēctecība

https://en.wikipedia.org/wiki/Superscalar_processor

https://en.wikipedia.org/wiki/Arithmetic_logic_unit

https://arith-matic.com/notebook/arithmetic-logic-unit-introduction

https://en.wikipedia.org/wiki/74181

https://en.wikipedia.org/wiki/7400-series_integrated_circuits

 

https://drukatava.lv/bookshop/product/ciparu-elektronika/

Link to comment
Share on other sites

Liam Ethernety
pirms 8 stundām , M_J teica:

Ko lai dara, ja maksā daudzos gadījumos tieši par lietām, kas galīgi neliekas interesantas.

 

pirms 8 stundām , ieleja teica:

 

skolā ir īstais laiks darīt tādas lietas savai attīstībai, atceros, bija jārada sava OS, diez vai manā universitātē kāds radīja ko paliekošu, bet citreiz pieauguši cilvēki taisa jaunu OS vai programēšanas valodu, “labāku par C”, vismaz pašuprāt

 

 

Varētu padiskutēt par to, cik daudz ir "veselīgi" ārpus darba laika nodarboties ar pašattīstošām lietām. Personīgi esmu bijis abos grāvjos - kādā dzīves posmā esmu to darījis gan ļoti daudz, gan citā posmā ļoti maz. Un redzu, ka ar to ļoti strugglo arī daudzi citi kolēģi. Bija man etaps, kad pēc 8h darba vēl katru dienu kādas 2-3h mācījos ar darbu nesaistītas lietas programmēt, bez brīvdienām. Tad sajutu, ka tas sit pa veselību un pārtraucu gandrīz pilnībā, līdz kārtējā darba "performance review" sapratu, ka man grūti nosaukt lietas, kā esmu pēdējā pusgada laikā pilnveidojies. Pēc tā gadījuma atkal palielināju laiku, kas tiek veltīts kaut kāda veida "mācībām" un tā līdz šim tas ir kaut kā lēkājis te uz augšu, te uz leju...

 

Dažkārt dzirdot, ja kādi kolēģi apspriež tehnoloģiju, par kuru pats neesi īsti lietas kursā, gribot negribot ieslēdzas kaut kāds fear of missing out. Un tad ir jautājums vai tev vajag investēt pašam laiku tās tehnoloģijas izpētē, vai nevajag. Atmaksāsies/neatmaksāsies, utt.

 

Pieejamo valodu/tooļu/instrumentu klāsts jau tā ir neiedomājami plašs, bet vēl katru dienu kāds hipsters izdomā kādu jaunu tooli/valodu/instrumentu. Vai tas maz vēl ir veselīgi IT jomas darbiniekiem... Vai ir veselīgi programmētājam vienlaicīgi labi orientēties kādās 4 ekosistēmās...

Labots - Liam Ethernety
Link to comment
Share on other sites

Liam Ethernety
pirms 16 stundām , Inspektors Caps teica:

Tagad padomājiet kādu titānisku inženieru pūliņu dēļ jūsu Electron un citu websūdu bāzētās hipsteru ne-do-aplikāciju parodijas vispār spēj pakustēties. Un tad padomājiet kā tās lidotu, tērējot 20x mazāk elektrības un strādātu 20x ilgāk, ja tās nebūtu veidotas no mēsliem...

 

Pie reizes domājot par elektrību un milisekundēm vajadzētu arī padomāt kādas būtu bijušas produktu ("websūdu") radīšanas izmaksas, laiks, prototipēšana, jaunu versiju palaišana, iterations... Biznesa prasības galu galā.

Citiem vārdiem sakot - tirgus ir visu nolicis pa plauktiņiem tā, kā tam ir jābūt. Filozofēt par to, ka visu vajag darīt ar assambleri, jo tad mēs tērēsim 20x mazāk elektrības, ir kaut kā jocīgi.

 

Link to comment
Share on other sites

Raimonds1
pirms 8 stundām , ieleja teica:

 

skolā ir īstais laiks darīt tādas lietas savai attīstībai, atceros, bija jārada sava OS, diez vai manā universitātē kāds radīja ko paliekošu, bet citreiz pieauguši cilvēki taisa jaunu OS vai programēšanas valodu, “labāku par C”, vismaz pašuprāt

 

 

Pieņemsim, ka kādi aktīvisti, ņemot vērā visu to, kas līdz šim saražots, izdomā sākt VISU  no jauna. Ar šodienas kļūdu un panākumu pieredzi un šodienas iespējām. Ko darītu citādi?

Link to comment
Share on other sites

Liam Ethernety
Pirms 10 minūtēm , Raimonds1 teica:

 

Pieņemsim, ka kādi aktīvisti, ņemot vērā visu to, kas līdz šim saražots, izdomā sākt VISU  no jauna. Ar šodienas kļūdu un panākumu pieredzi un šodienas iespējām. Ko darītu citādi?

 

Tā ir ļoti slikta doma. Ja tev jau ir strādājoša produkcijas sistēma, tad to pēkšņi pārrakstīt no nulles neskaidru mērķu vārdā ir ļoti slikti, dārgi un nelietderīgi. Tas ir pat runājot vienas lietotnes kontekstā, bet tu jau te vēl vispār piesauc "visa" sākšanu no jauna, lai ko tas arī nozīmētu. 🙂

 

Sistēmai atrodoties produkcijas vidē tā ar laiku "noslīpējas", atrodas bugi, ko izstrādes laikā neviens nepamanīja. Sistēma ilgstošā laika posmā ir saņēmusi reālistisku noslodzi un cilvēki ir guvuši reālistisku pieredzi par to kā esošo sistēmu vislabāk uzturēt/papildināt. Tas ir ļoti svarīgi. Uzrakstot sistēmu atkal no nulles, tai neizbēgami būs kaut kādas cita veida problēmas, kuras vajadzēs laika gaitā noslīpēt.

 

Labs bloga raksts par tēmu: https://cdruc.com/rewriting-applications-a-bad-idea/

 

Pareizā lieta ko darīt ir identificēt kādu specifisku problēmu un to novērst. "visa" pārrakstīšana ir nonsenss, praktiski vienmēr.

Labots - Liam Ethernety
Link to comment
Share on other sites

Inspektors Caps

@Liam Ethernety, Tu nonāc pretrunās. Ja augstskolas mācītu inženierus, nevis štancētu debīleņu rindas, tad nekādu grandiozo izmaksu labākam softam nebūtu. Nevajag te fleitēt par asambleru un neizliecies, ka neeksistē Qt un līdzīgi freimworki. Pat puskompilēto .NET te var pieminēt kā relatīvi labo piemēru. Pie tam, ja virzītos uz progresu, labu freimworku būtu daudz vairāk. Vēl Tu argumentē, ka pārtaisīt visu ir dumji, un lielā mērā tā arī ir, bet paskaties piemērus tieši ar websūdiem, piemēram Skype. Kad tā bija puslīdz normāla programma, tā valdīja pār pasauli. Kad pie tās Microsoft-ā ķērās klāt hipsterdebīliķi, sāka pārtaisīt visu un pie tam pārtaisīja par Electron bāzētu websūdu, "attīstīt" bezkrāsu neergonomiska bezgaumīga GUI un geju "ģimeņu" smailiju virzienā, tad... Skype nomira. Nerunājot par to, ka lētāk bija nepārtaisīt visu, tieši pārtaisīšana uz websūdu tā vietā, lai attīstītu reāli nepieciešamās funkcijas, to nobeidza. Pēc vēl 10 gadiem par to vairs liecinās tikai Wikipedia raksts.

 

Visi tie "pofig 20x performance" ir tipiskie argumenti tiem, kuri nedomā tālāk par vienu soli. Tik pat labi es tad saku, ka pārvietoties var arī ar zirgu, elektrību nevajag un vispār var dzīvot alā. Un tiešām var, bet tas ir regress attīstībā! Jebkurā jomā tad, kad kvantitatīvās iespējas pieaug vairākas reizes, tas rada principiāli jaunus tās tehnoloģijas pielietojumus.

  • Patīk 1
Link to comment
Share on other sites

1 stundu atpakaļ, Liam Ethernety teica:

Dažkārt dzirdot, ja kādi kolēģi apspriež tehnoloģiju, par kuru pats neesi īsti lietas kursā, gribot negribot ieslēdzas kaut kāds fear of missing out. Un tad ir jautājums vai tev vajag investēt pašam laiku tās tehnoloģijas izpētē, vai nevajag. Atmaksāsies/neatmaksāsies, utt.

 

Nepatīk domāt kategorijās atmaksāsies/neatmaksāsies. Bet pie CAN apguves nonācu vajadzības spiests, lai gan plati ar CAN kontrolieri biju uzzīmējis un izmantoju jau sen, tikai neizmantoju to CAN daļu. Tagad vajadzība spieda to apgūt un ir arī interesanti. Ja rēķina kategorijās atmaksāsies/neatmaksāsies, protams, ka par konkrēto izpēti atsevišķi neviens nemaksās, maksā par projektu kopumā, kur ir gana daudz bezgala garlaicīgas, toties labi apmaksātas pozīcijas.

 

1 stundu atpakaļ, Liam Ethernety teica:

Pie reizes domājot par elektrību un milisekundēm vajadzētu arī padomāt kādas būtu bijušas produktu ("websūdu") radīšanas izmaksas, laiks, prototipēšana, jaunu versiju palaišana, iterations... Biznesa prasības galu galā.

Citiem vārdiem sakot - tirgus ir visu nolicis pa plauktiņiem tā, kā tam ir jābūt. Filozofēt par to, ka visu vajag darīt ar assambleri, jo tad mēs tērēsim 20x mazāk elektrības, ir kaut kā jocīgi.

It kā tirgus ir nolicis visu pa plauktiņiem, bet no otras puses, ja paskaties uz kādu lietu un redzi acīmredzamas lietas, kas ir jātaisa savādāk, kāpēc atražot kaut ko, ko uzskati par aplamu, tikai tāpēc, ka tā dara visi, un tirgus ir visu nolicis pa plauktiņiem. Turklāt ļoti regulēts tirgus. Salīdzinot ar to, kā ir attīstījusies auto elektronika un motoru vadības sistēmas automobiļos, es biju šokā, ieraugot, kādā līmenī ir vadības sistēmas elektrostaciju gāzes motoriem. Tur valda senvēsture! 21. gadsimta motoriem aizdedze ir no kāda 75. gada, bet puse no vadības automātikas loģikas ir būvēta uz relajiem, atkārtojot vēsturē pirmos mēģinājumus radīt skaitāmās mašīnas. Tam visam kaut kā tiek piekabināts tačskrīns un internets. Nesaprotu, kāpēc lampu etaps ir izlaists. Es nezinu, ko Woodward, Heinzmann un citi šīs jomas "līderi" ir samaksājuši vai kādā citā veidā sarunājuši, piemēram ar Bosch, ka tas nenāk viņu lauciņā un ar vienu vēzienu neaizslauka viņus vēstures mēslainē?

Link to comment
Share on other sites

AndrisBB
Pirms 57 minūtēm , Inspektors Caps teica:

Skype nomira.

Kur teikts ka Skype nomira? Varbūt tas r taspats Teams.


Pirms 45 minūtēm , M_J teica:

Tur valda senvēsture! 21. gadsimta motoriem aizdedze ir no kāda 75. gada, bet puse no vadības automātikas loģikas ir būvēta uz relajiem

Tapēc ka to visu nomainīt vai izgudrot nojauna ar jaunākām tehnalogijām ir dārgi. Viskautko var uzlabot un atjaunināt, bet tas viss maksās astronomiskas summas. Tu kā inženieris tur redzi relejus, bosi tur redz strādājošu sistēmu, kuru upgreidojot nebūs nekāda praktiska ieguvuma.

Karo4e, ja strādā, tad nav ko aiztikt.

Link to comment
Share on other sites

Pirms 9 minūtēm , AndrisBB teica:

Tapēc ka to visu nomainīt vai izgudrot nojauna ar jaunākām tehnalogijām ir dārgi. Viskautko var uzlabot un atjaunināt, bet tas viss maksās astronomiskas summas. Tu kā inženieris tur redzi relejus, bosi tur redz strādājošu sistēmu, kuru upgreidojot nebūs nekāda praktiska ieguvuma.

 

Karo4e, ja strādā, tad nav ko aiztikt.

 Tur jau tā lieta, ka no tā rodas virkne problēmu. Loģika, kas uzbūvēta uz simtiem releju ir tieši tik droša, cik jābūt loģikai, kas būvēta uz simtiem releju. Pēkšņi kaut kas neiet. Elektrostacija stāv divas dienas, kamēr atbrauc apkalpojošais inženieris, kurš arī neko neatrod, bet kārtīgi uzsit pa skapja vienu stūri, sistēma aiziet un klientam tiek izrakstīts četrciparu rēķins. Nākošo reizi vietējais operators jau zina, pa kurieni ir jāuzsit. Kad uzsišana vairs nepalīdz, atkal tiek saukts apkopes inženieris. Šajā reizē viņš neuzsit, bet uzvelk vienu vadiņu no viena kastes stūra uz citu, apejot kādu ķēdi. Klientam viņš paskaidro, ka šī ķēde tāpat nav svarīga un viss strādā gandrīz kā iepriekš, tikai uz ekrāna visu laiku deg kāds dzeltens brīdinājums. Dzeltens, nevis sarkans, tātad strādāt var. Tā tiek paskaidrots klientam. Atklātā sarunā uzzinu, ka patiesībā servisa inženieris pats nezina, kā šī ķēde strādā, viņš nepazīst nevienu, kas to zinātu, bet kaut kādos kursos viņš ir uzzinājis, kā to ķēdi var apiet, un nekas slikts nenotiekot.

  • Atbalstu 1
  • Haha 2
Link to comment
Share on other sites

Liam Ethernety
Pirms 9 minūtēm , M_J teica:

 Tur jau tā lieta, ka no tā rodas virkne problēmu. Loģika, kas uzbūvēta uz simtiem releju ir tieši tik droša, cik jābūt loģikai, kas būvēta uz simtiem releju. Pēkšņi kaut kas neiet. Elektrostacija stāv divas dienas, kamēr atbrauc apkalpojošais inženieris, kurš arī neko neatrod, bet kārtīgi uzsit pa skapja vienu stūri, sistēma aiziet un klientam tiek izrakstīts četrciparu rēķins.

 

Jā, protams, nav ideāli, bet pieņemu, ka modernizēšanai būtu labākajā gadījumā septiņu ciparu rēķins

Link to comment
Share on other sites

Pirms 13 minūtēm , Liam Ethernety teica:

Jā, protams, nav ideāli, bet pieņemu, ka modernizēšanai būtu labākajā gadījumā septiņu ciparu rēķins

Ja uzticēt modernizēšanu tiem pašiem, kas projektēja jau esošās šausmas, tad noteikti.

  • Patīk 1
Link to comment
Share on other sites

Inspektors Caps

@M_J, grūti tā uz sitiena iebraukt cita CPU un asamblera niansēs. Cik saprotu, CPU ir 8-bit AVR, nezinu kāds asamblers. Drīzāk tīri interesanti būtu, ja Tu pats pakomentētu šo. Bet uzreiz ir skaidrs, ka arī tad salīdzinājums nesanāk gluži 1:1, jo Tu veselu čupu reģistru sistēmas mērogā rezervē tikai šim vienam mērķim. Lielākā firmware tā būtu diezgan liela izšķērdība attiecībā pret citām funkcijām.

 

Kādēļ tās dēļ kvarciem atšķirīgās CAN frekvences nenoteici ar osciloskopu vai loģisko analizatoru? Cik saprotu, tā mistiskā iemesla dēļ Tu taisīji bit-bang...

 

Saproti mani pareizi - es arī esmu par lietu izpratni un optimālām sistēmām. Bet nav izdevīgi tērēt laiku uz lietām, ko citi jau ir izdarījuši labā līmenī. Un CAN bit-bang ir tieši tāda... Laiku vajag tērēt uz tām jomām, kas šobrīd ir sliktā līmenī vai vēl labāk vēl vispār neeksistē! Es arī zinu Ethernet freimus līdz baitam/bitam, bet tādēļ es netaisīšu savu MAC perifēriju. Kur nu vēl bit-bang, kas gandrīz nav iespējams, jo MII/RMII interfeisi ir ar 25/50 MHz attiecīgi. Savu MAC ir jēga taisīt uz FPGA tikai tad, ja ir nepieciešamas funkcijas, kādu nav gatavajiem, vai tas ir izdevīgi lielākā projektā integrācijas dēļ. Nu, vai tad, ja esi pusvadītāju ražotājs. Tā vietā paņem kādu 32-bit MCU ar Cortex-M, MIPS vai drīz arī RISC-V, kam CAN, Ethernet vai ko nu vajag ir dzelžos, un izstrādā jaunas paaudzes vadības sistēmas tiem elektrostaciju gāzes motoriem vai jebko citu, kur šobrīd industrija ir sliktā stāvoklī.

 

Netriviāliem projektiem software/hardware ieguldāmā darba apjoma (un pēc tam pievienotās vērtības) attiecība ir tāda, ka vismaz 80% un bieži daudz vairāk ir software pusē. Pat nerunājot par desktop un telefonu programmatūras traģisko stāvokli, MCU līmeņa embedded programmatūra industrijā ir labākā, bet tāpat ļoti sliktā stāvoklī. Piemēram, kad vajag multi-thread kerneli, tad ir daudz jēdzīgu gan komerciālu, gan bezmaksas piedāvājumu, no kuriem populārākais ir FreeRTOS, kas ir tiešām jēdzīgs. Bet ko ņemt tad, kad nav real-time prasību, bet ir svarīgs izmērs un robustums? Tipiski to sauc par bare metal, kas to arī nozīmē - nav nekā. Un tad nu katrs mudī flagus, taskus, kritiskās sekcijas un taimerus katru reizi no nulles un katrā vietā savādāk. Un to visu, protams, darbina stulbs super-loop, kas cikliski pollo visu. Neskatoties uz to, ka CPU ir 100% aizņemts pilnīgi vienmēr, sistēmas response laiks un citi veiktspējas aspekti ir daudz sliktāki kā būtu ar adekvātu kooperatīvo šeduleri plus kods ir nevajadzīgi sarežģīts un nepārskatāms, kas palielina kļūdu iespējamību. Un kāda ir situācija ar software taimeriem sistēmām bez RTOS? Tādu gandrīz nav! Tie daži piemēri, kas ir atrodami, ir mēsli. Bet software taimeri ir nepieciešamība vismaz 80% netriviālos projektos. Tad vēl labs piemērs ir lietotāja konfigurācijas propertiju menedžēšana. Nodrošināt defaultās vērtības, "reset to defaults", ievadīto datu pārbaudi, drošu saglabāšanu dažādās atmiņās (flash, EEPROM, FRAM gan lokāli, gan caur I2C, SPI u.c.), flash atmiņas rakstīšanas reižu skaita un ilgas dzēšanas nianšu ņemšana vērā, unificēt datu tipus un defaultās darbības ar propertijiem, bet būt iespējai katram implementēt custom darbības - cik šādu bibliotēku zināt? Es meklēju... Apaļa nulle! Tā ir idiokrātija!

Labots - Inspektors Caps
Link to comment
Share on other sites

Izveido kontu, vai pieraksties esošajā, lai komentētu

Jums ir jābūt šī foruma biedram, lai varētu komentēt tēmas

Izveidot jaunu kontu

Piereģistrējies un izveido jaunu kontu, tas būs viegli!

Reģistrēt jaunu kontu

Pierakstīties

Jums jau ir konts? Pierakstieties tajā šeit!

Pierakstīties tagad!
 Share

×
×
  • Izveidot jaunu...