Re: C: Arduino : Přesun pole bytů do proměnné unsigned long

Jan Waclawek konfera na efton.sk
Středa Listopad 8 20:02:47 CET 2023


>A protoze jsem na mnoooohoregistrove architekture nikdy nic nedelal - 
>proc v druhem pripade pouziva r20, r18, r19, r24 pro ten prvni radek, a 
>ne porad dokola jen jeden registr? 

Neviem.

>To uz tam je pouzit nejaky 
>pipelining, takze ty instrukce jedou paralelne? (takze by jim sdileni 
>registru zpusobovalo cekani?)

Nie, toto je slusny skalarny procesor.

Ten avr-gcc je tak trocha ryborak, lebo pokial viem, frontend gcc preklada
do abstraktneho stroja ktory je minimalne 32-bitovy (a ma nekonecne
mnozstvo pracovnych registrov), takze potom ta 8/16-bitovost AVR v
skutocnosti vyzaduje nejake dodatocne optimalizaciu v back-ende, kde sa
alokuju aj registre. Ale v tomto pripade, kedze to prekladac zrejme vidi
ako "ciste 32-bitovu zalezitost" asi ide o to, ze sa priamociaro
instrukcia abstraktneho stroja "nacitaj a uloz jedno 32 bitove slovo"
implementovala ako "nacitaj 32-bitov a potom uloz 32 bitov".

Naviac r26-r31 su "precious" registre, lebo sa pouzivaju aj ako bazove
registre (X, Y, Z) pre indexove instrukcie, takze tam je zase nejaky tlak
nejake registre uvolnovat. Toto dohromady potom moze sposobovat, ze ta
alokacia registrov je relativne zmatena vec a preto potom v tom druhom
riadku druheho pripadu zacne pouzivat aj r12-r15.

Ale blizsie som to neskumal.

wek




----- Original Message ---------------

Subject: Re: C: Arduino : Přesun pole bytů do proměnné unsigned long
   From: Jindroush <jindroush na seznam.cz>
   Date: Wed, 8 Nov 2023 19:47:42 +0100
     To: HW-news <hw-list na list.hw.cz>

>Toto je ale velmi vtipne, ten rozdil!
>To vypada, jako by si optimalizator v tom druhem pripade nedokazal dat 
>dohromady, ze bb.b[0...3] je totez jako bb.w32, jako prosty alias, takze 
>to provedl ve dvou nezavislych operacich.
>V prvnim pripade mezivysledek rovnou pouzil v druhem radku.
>
>A protoze jsem na mnoooohoregistrove architekture nikdy nic nedelal - 
>proc v druhem pripade pouziva r20, r18, r19, r24 pro ten prvni radek, a 
>ne porad dokola jen jeden registr? To uz tam je pouzit nejaky 
>pipelining, takze ty instrukce jedou paralelne? (takze by jim sdileni 
>registru zpusobovalo cekani?)
>
>J.
>
>
>On 08.11.2023 19:34, Jan Waclawek wrote:
>>
>> Pricom odvolavam co som odvolal. Skusil som niekolko sposobov na niekolkych
>> verziach gcc, a "optimalne" fungoval naozaj len ten cez type punning cez
>> pretypovanie smernika...
>>
>>    b1 = *(uint32_t*)&rx[3];
>>    c = b1;
>>
>>    27 0018 8091 0000 		lds r24,rx+3
>>    28 001c 9091 0000 		lds r25,rx+3+1
>>    29 0020 A091 0000 		lds r26,rx+3+2
>>    30 0024 B091 0000 		lds r27,rx+3+3
>>    31 0028 8093 0000 		sts b1,r24
>>    32 002c 9093 0000 		sts b1+1,r25
>>    33 0030 A093 0000 		sts b1+2,r26
>>    34 0034 B093 0000 		sts b1+3,r27
>>    35 0038 8093 0000 		sts c,r24
>>    36 003c 9093 0000 		sts c+1,r25
>>    37 0040 A093 0000 		sts c+2,r26
>>    38 0044 B093 0000 		sts c+3,r27
>>
>>    bb.b[0] = rx[3]; bb.b[1] = rx[4]; bb.b[2] = rx[5]; bb.b[3] = rx[6];
>>    c = bb.w32;
>>
>>    39 0048 4091 0000 		lds r20,rx+3
>>    40 004c 4093 0000 		sts bb,r20
>>    41 0050 2091 0000 		lds r18,rx+4
>>    42 0054 2093 0000 		sts bb+1,r18
>>    43 0058 3091 0000 		lds r19,rx+5
>>    44 005c 3093 0000 		sts bb+2,r19
>>    45 0060 8091 0000 		lds r24,rx+6
>>    46 0064 8093 0000 		sts bb+3,r24
>>    47 0068 C090 0000 		lds r12,bb
>>    48 006c D090 0000 		lds r13,bb+1
>>    49 0070 E090 0000 		lds r14,bb+2
>>    50 0074 F090 0000 		lds r15,bb+3
>>    51 0078 C092 0000 		sts c,r12
>>    52 007c D092 0000 		sts c+1,r13
>>    53 0080 E092 0000 		sts c+2,r14
>>    54 0084 F092 0000 		sts c+3,r15
>>
>
>-- 
>Jindroush <jindroush na seznam.cz>
>
>_______________________________________________
>HW-list mailing list  -  sponsored by www.HW.cz
>Hw-list na list.hw.cz
>http://list.hw.cz/mailman/listinfo/hw-list



Další informace o konferenci Hw-list