*****SPAM***** Re: C _ jak rozepsat ?__ádek

Jaroslav Buchta jaroslav.buchta na hascomp.cz
Neděle Duben 28 21:33:27 CEST 2013


Vzhledem k tomu, ze memcpy ma ukazatele jako void* tak se musi poprat se 
vsemi zaludnostmi, ne? Taky jsem to jednou zkoumal a zarovna si zacatek, 
konec po Bytech nebo half wordech a prostredek jede po wordech...
Zrovna tak jako memmove by mela resit prekryti oblasti libovolnym zpusobem.

Dne 28. 4. 2013 17:14, Miroslav Mraz napsal(a):
> Faktem je, že jsem se tomu memcpy() z newlib koukal trochu pod sukně a
> vypadá to, že s nezarovnaným přístupem počítá a zřejmě i optimalizuje
> počet cyklů právě podle toho zarovnání. A hlavně funguje i s tou lichou
> adresou. Po vašem upozornění jsem to ale stejně předělal a používám svou
> vlastní funkci, která dělá prostou bytovou kopii:
>
>    25:../protokol.h **** /// memcpy s malou úpravou (pro firmware)
>    26:../protokol.h **** static inline uint32_t nmemcpy (void* dst, const
> void* src, uint32_t len) {
>    28 0000 10B5     		push	{r4, lr}
>    27:../protokol.h ****   register uint32_t i;
>    28:../protokol.h ****   uint8_t* d = (uint8_t*) dst;
>    29:../protokol.h ****   uint8_t* s = (uint8_t*) src;
>    30:../protokol.h ****   for (i=0; i<len; i++) d[i] = s[i];
>    34 0002 0023     		mov	r3, #0
>    35 0004 02E0     		b	.L2
>    37              	.L3:
>    39 0006 CC5C     		ldrb	r4, [r1, r3]
>    40 0008 C454     		strb	r4, [r0, r3]
>    41 000a 0133     		add	r3, r3, #1
>    43              	.L2:
>    45 000c 9342     		cmp	r3, r2
>    46 000e FAD1     		bne	.L3
>    31:../protokol.h ****   return len;
>    32:../protokol.h **** }
>    48 0010 181C     		mov	r0, r3
>    51 0012 10BD     		pop	{r4, pc}
>
> To vypadá, že bude bez problémů, řekl bych, že takovéto přetypování bude
> bezpečné, je to hezky čitelné. LDRB a STRB zřejmě lichou adresu zkousne.
> Zase tak velké bloky dat se tam nepřenášejí a je na to čas. Ten váš
> postup s násobením (resp. shiftem) a skládáním je správnější, protože
> řeší i endienitu, ale mě se zde nehodí (dst může být ve skutečnosti
> pointer na nějakou strukturu definovanou protokolem) a nejsem zrovna
> purista, přenášet to na BE nebudu (není to kde vyzkoušet).
> Moc díky za připomínky.
>
> To s tím nečtením návodů berte spíš jako vtip. Ale spousta známých se
> tím fakt řídí. Jinak jsem se za své poměrně dlouhé praxe s problémy
> záhadných chyb v programu moc nesetkal. Buď mám kliku nebo spíš nějaký
> blíže nedefinovatelný záhadný cit pro potenciální problémy. Více byly
> problémy ze začátku, kdy to člověk mastil v assembleru v jednom souboru
> a neměl zas tak moc zkušeností. V Céčku snad jen jednou, kdy protějšek
> psal kolega a chodily mě od něj záhadná data v hlavičkách paketů. Blbě
> jsme se domluvili a on používal nepakovanou strukturu a já pakovanou.
>
> Časem si člověk vypracuje určitý styl psaní, který mu vyhovuje a má ho
> vyzkoušený, že na dané platformě funguje. No a pak se objeví nová
> platforma, kde to už může způsobit problém jako v tomto případě. Pak je
> potřeba vyloupnout jádro problému a pak styl psaní programu přizpůsobit
> - jak doporučuje wek, nebo vytvořit nějaký obal, který by umožňoval
> použít stejný styl i zde. No a protože návyky se těžko mění, dal jsem se
> touto, možná špatnou cestou.
>
> Mrazík
>
>
> Jan Waclawek píše v Ne 28. 04. 2013 v 13:27 +0200:
>
>> To tiez nie je spravne; memcpy() s nezarovnanym pointrom moze a nemusi fungovat. Napriklad v Keili nefunguje, a je to podla normy uplne spravne. Problem je uz totiz v tom nezarovnanom pointri.
>>
>> Ved som Vam napisal, ako je to spravne (skladat pomocou nasobenia a scitania), tak preco sa storcujete?
>>
>> wek
>
> _______________________________________________
> 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