| |
|
  |
 ZLib для ARM, Где найти сорцы |
|
|
|
|
 Nov 28 2007, 10:19
|
Участник
Группа: Свой
Сообщений: 49
Регистрация: 29-03-06
Пользователь №: 15 592
|
Цитата(sergeeff @ Nov 27 2007, 23:23)  http://www.zlib.net/ - A Massively Spiffy Yet Delicately Unobtrusive Compression Library. У меня поставилась на ARM без малейших проблем. Поставилась - это только 10% всех проблем. Оно виснет/вылетает по exception при работе на всяких там операциях типа: Цитата #define DO1 crc = crc_table[0][((int)crc ^ (*buf++)) & 0xff] ^ (crc >> 8)
if (*((unsigned char *)(&endian))) Потому что проц настроен на проверку выравнивания памяти. Т.е. если R0 = 0x1000; STRB R1,[R0] - отработает нормально. Т.к. в R0 адрес кратный 4. А если R0 = 0x1001; STRB R1,[R0] - завалится. Т.к. в R0 адрес некратный 4. Если нужно писать по адресу 0x1001 должен генериться вот такой код: R0 = 0x1000; STRB R1,[R0,#1] Сорцы zlib должны учитывать выравнивание памяти. Пока что не могу нигде найти. p.s. Может как-то настроить можно компилер? Я на IAR'e.
Сообщение отредактировал Hexxx - Nov 28 2007, 10:20
|
|
|
|
|
|
|
|
Nov 28 2007, 10:28
|
Гуру
Группа: Свой
Сообщений: 10 713
Регистрация: 11-12-04
Пользователь №: 1 448
|
Цитата(Hexxx @ Nov 28 2007, 13:19) R0 = 0x1001;
STRB R1,[R0] - завалится. Т.к. в R0 адрес некратный 4. STRB никогда не завалится, ибо байты можно писать как угодно. Цитата(Hexxx @ Nov 28 2007, 13:19) Если нужно писать по адресу 0x1001 должен генериться вот такой код:
R0 = 0x1000;
STRB R1,[R0,#1] Способ адресации никак не влияет на корректность обращения к памяти.
|
|
|
|
|
|
|
|
Nov 28 2007, 12:40
|
Участник
Группа: Свой
Сообщений: 49
Регистрация: 29-03-06
Пользователь №: 15 592
|
Цитата(aaarrr @ Nov 28 2007, 14:28) STRB никогда не завалится, ибо байты можно писать как угодно.
Способ адресации никак не влияет на корректность обращения к памяти. То есть программисты фирмы Samsung писавшие драйвер OneNand на самом деле не шарят, и делают лишнюю работу, когда сами руками проверяют выравнивание адресов: Код VOID OAM_Memcpy(VOID *pDst, VOID *pSrc, UINT32 nLen)
{
register INT32 nCnt;
register UINT8 *pD8, *pS8;
register INT32 nL = nLen;
register UINT32 *pD32, *pS32;
pD8 = (UINT8*)pDst;
pS8 = (UINT8*)pSrc;
if ( ((INT32)pD8 % sizeof(UINT32)) == ((INT32)pS8 % sizeof(UINT32)) ) // ВОТ ЭТО!!!
{
while ( (INT32)pD8 % sizeof(UINT32) )
{
*pD8++ = *pS8++;
nL--;
if( nL <= 0 )
return;
}
pD32 = (UINT32*)pD8;
pS32 = (UINT32*)pS8;
for (nCnt = 0; nCnt <(INT32)(nL / sizeof(UINT32)); nCnt++)
*pD32++ = *pS32++;
pD8 = (UINT8*)pD32;
pS8 = (UINT8*)pS32;
while( nL % sizeof(UINT32) )
{
*pD8++ = *pS8++;
nL--;
}
}
else
{
for( nCnt = 0; nCnt < nL; nCnt++)
*pD8++ = *pS8++;
} Нашел вот еще на сайте ARM'a: The ARM compiler assumes that all pointers are naturally-aligned (i.e. int* is word-aligned, short* is halfword-aligned, etc.). You need to either explicitly tell the compiler when you are using unaligned pointers by using the __packed keyword or create a temporary char* pointer to access the addressКод #include <string.h>
unsigned int * const dest;
void example (unsigned int * const unaligned_ptr)
{
__packed unsigned int * packed_ptr = unaligned_ptr;
char * temp_ptr = (char *)unaligned_ptr;
memcpy(dest, unaligned_ptr, 32); /* Unsafe */
memcpy(dest, (void *)packed_ptr, 32); /* Safe */
memcpy(dest, temp_ptr, 32); /* Safe */
} То есть проблема реально существует. И сорцы с сайт'а zlib не будут работать там, где включено выравнивание указателей. Еще раз спрашиваю, где есть сорцы zlib с учетом выравнивания?
Сообщение отредактировал Hexxx - Nov 28 2007, 12:40
|
|
|
|
|
|
|
|
Nov 28 2007, 13:51
|
Гуру
Группа: Модераторы
Сообщений: 8 455
Регистрация: 15-05-06
Из: Рига, Латвия
Пользователь №: 17 095
|
Цитата(Hexxx @ Nov 28 2007, 14:40) Нашел вот еще на сайте ARM'a:
or create a temporary char* pointer to access the address Вот именно - доступ по байтовому (char*) указателю может производиться к любому байту, независимо от выравнивания всей переменной. никакого противоречия нет.
--------------------
На любой вопрос даю любой ответ"Write code that is guaranteed to work, not code that doesn’t seem to break" ( C++ FAQ)
|
|
|
|
|
|
|
|
Nov 29 2007, 15:26
|
Участник
Группа: Свой
Сообщений: 49
Регистрация: 29-03-06
Пользователь №: 15 592
|
Цитата(sergeeff @ Nov 28 2007, 19:54) Еще раз, может кто не понял. Эта библиотека одна из немногих, которая откомпилировалась сразу и используется больше года на реальном железе. Никаких data-abort и прочего из-за невыравнивания данных. В компиляторе указано выравнивание равное 4. Вполне возможно, что я неправ. Объясните мне пожалуйста зачем тогда нужно было программистам Samsung делать такой странный код OAM_Memcpy().
Сообщение отредактировал Hexxx - Nov 29 2007, 15:26
|
|
|
|
|
|
|
|
 Nov 29 2007, 15:47
|
Группа: Участник
Сообщений: 5
Регистрация: 10-05-07
Пользователь №: 27 632
|
Цитата(sergeeff @ Nov 27 2007, 22:23) http://www.zlib.net/ - A Massively Spiffy Yet Delicately Unobtrusive Compression Library. У меня поставилась на ARM без малейших проблем.  А у меня библиотека так и не стала из-за того же 4-х байтового выравнивания Цитата(aaarrr @ Nov 28 2007, 13:28) Способ адресации никак не влияет на корректность обращения к памяти. Мне пришлось писать функцию int ToInt(const char*); и ей подобные из-за того, что операция *(int*)buff вылетает в том случае, если buff не выровнен.
|
|
|
|
|
|
|
|
Nov 29 2007, 16:20
|
Гуру
Группа: Свой
Сообщений: 10 713
Регистрация: 11-12-04
Пользователь №: 1 448
|
Цитата(Hexxx @ Nov 29 2007, 18:26) Вполне возможно, что я неправ. Объясните мне пожалуйста зачем тогда нужно было программистам Samsung делать такой странный код OAM_Memcpy(). Код у китайцев действительно странный. Точнее, не до конца оптимизированный. Писать слова по не выровненным адресам, естественно, нельзя. Цитата(Ailinor @ Nov 29 2007, 18:47) Мне пришлось писать функцию int ToInt(const char*); и ей подобные из-за того, что
операция *(int*)buff вылетает в том случае, если buff не выровнен. Я писал о способе адресации, а не о разрядности данных. Т.е. что фрагменты: Код R0 = 0x1001;
STR R1,[R0] и Код R0 = 0x1000;
STR R1,[R0,#1] вылетят с одинаковым успехом.
|
|
|
|
|
|
|
|
Nov 30 2007, 05:44
|
Профессионал
Группа: Свой
Сообщений: 1 975
Регистрация: 30-12-04
Из: Воронеж
Пользователь №: 1 757
|
Цитата(aaarrr @ Nov 29 2007, 19:20) Код у китайцев действительно странный. У корейцев. Цитата Точнее, не до конца оптимизированный. Точнее, не у корейцев, а у индусов. Наверняка, они писали.
|
|
|
|
|
|
|
|
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|
