как реализовать алгоритм контрольной суммы???

Тема в разделе "WASM.CRYPTO", создана пользователем abcd008, 5 дек 2010.

  1. abcd008

    abcd008 New Member

    Публикаций:
    0
    Регистрация:
    8 фев 2009
    Сообщения:
    616
    Я делаю драйвер acpi и там в таблицах используется алгоритм контрольной суммы.
    он заключается в сложении всех байт и байта контрольной суммы, сумма должна получиться равной 0.

    как можно оптимально реализовать этот алгоритм?
    можно конечно складывать по байтно, но мне кажется это долго, можно ли сделоть как-то быстрее???

    заранее благодарен.
     
  2. artkar

    artkar New Member

    Публикаций:
    0
    Регистрация:
    17 авг 2005
    Сообщения:
    400
    Адрес:
    Russia
    Дык этж наверно наш старый добрый CRC??? Сложение по ксору?
     
  3. abcd008

    abcd008 New Member

    Публикаций:
    0
    Регистрация:
    8 фев 2009
    Сообщения:
    616
    я его смотрел их там много, какой именно надо.
    я его либо не првильно понял, либо он работает по другому.
     
  4. persicum

    persicum New Member

    Публикаций:
    0
    Регистрация:
    2 фев 2007
    Сообщения:
    947
    Может складывать по 32бита, потом сложить все четыре байта результата и хвостик отдельно побайтам?

    Если под суммой имеется в виду 8битная CRC8, то порциями по 32 бит тоже можно, только число таблиц возрастет с одной до четырех. Большого выигрыша может и не быть.
     
  5. abcd008

    abcd008 New Member

    Публикаций:
    0
    Регистрация:
    8 фев 2009
    Сообщения:
    616
    идея неплохая я до этого не дадумался.

    а crc это вроде с делением, и его остатком...


    в mmx есть инструкция сложения сразу по 4 байта(вроде), тока я не знаю будет ли она быстрее или пока буду инициировать данные, уже потеряю в выиграше.
     
  6. KeSqueer

    KeSqueer Сергей

    Публикаций:
    0
    Регистрация:
    19 июл 2007
    Сообщения:
    1.183
    Адрес:
    Москва
    persicum
    Так нельзя делать. Пример:
    0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF
    Ваш алгоритм: 0xFFFFFFFF + 0xFFFFFFFF =0x(1)FFFFFFFE. 0xFF + 0xFF + 0xFF + 0xFE = 0x(3)FB.
    Правильный алгоритм: 8*0xFF = 0x(7)F8.
    В скобках "невлезшие" байты.
    Разве что пробовать MMX-подобные инструкции, где нет переноса разряда в старший байт при переполнении.
     
  7. persicum

    persicum New Member

    Публикаций:
    0
    Регистрация:
    2 фев 2007
    Сообщения:
    947
    KeSqueer
    Для такого "надежного" алгоса для суммы может и XOR хватило бы?

    Ошибку признаю, про переносы из головы вылетело =)))

    Если нужно распараллелить, то следует смотреть в сторону MMX

    PADDB должен помочь (кажись, работает без знака и насыщения?):

    PADDB mm0,[esi]
    PADDB mm1,[esi+8]
    ...
    PADDB mm7,[esi+56]

    а в конце цикла перескладывать все регистры нафиг!

    PADDB mm0,mm1
    ...
    PADDB mm0,mm7
     
  8. abcd008

    abcd008 New Member

    Публикаций:
    0
    Регистрация:
    8 фев 2009
    Сообщения:
    616
    я тоже думаю так сделать, тлько не знаю стоит ли заморачиваться с mmx для 5-6 таблиц acpi.
    не будет ли сама инициализация регистров mmx занимать больше времени чем просто сложение???
     
  9. persicum

    persicum New Member

    Публикаций:
    0
    Регистрация:
    2 фев 2007
    Сообщения:
    947
    pxor mm0,mm0
    pxor mm1,mm1
    ....

    Можно в принципе и одним регистром mm0 обойтись, все равно будет в 8 раз быстрее.
     
  10. abcd008

    abcd008 New Member

    Публикаций:
    0
    Регистрация:
    8 фев 2009
    Сообщения:
    616
    всем спасибо