Команды сравнение строк в ассемблере нет?
От: lamai  
Дата: 18.11.19 18:47
Оценка: -3 :))) :)

xor eax,eax ;флаг результата. Если 0 — строки НЕ равны
mov esi,offset string1
mov edi,offset string2
repe cmpsb
jne done
inc eax ;флаг результата = 1, строки равны
done:
;если Eax = 0 — строки не равны, если 1 — равны.


До сих пор нужно писать внешний цикл при сравнении строк? Нельзя загрузить в процессор адреса нуль-терминированных строк, выполнить одну команду и получить результат?
Re: Команды сравнение строк в ассемблере нет?
От: bzig  
Дата: 18.11.19 19:26
Оценка: +1
L>До сих пор нужно писать внешний цикл при сравнении строк? Нельзя загрузить в процессор адреса нуль-терминированных строк, выполнить одну команду и получить результат?

До сих пор не используешь Unicode для своих строк? А то в них нулевой байт может появиться в самом неожиданном месте.
Re: Команды сравнение строк в ассемблере нет?
От: Muxa  
Дата: 18.11.19 19:30
Оценка: +3 :))) :)))
L>До сих пор нужно писать внешний цикл при сравнении строк? Нельзя загрузить в процессор адреса нуль-терминированных строк, выполнить одну команду и получить результат?

... и чтобы отработало за константное число тактов
Re[2]: Команды сравнение строк в ассемблере нет?
От: ononim  
Дата: 18.11.19 19:33
Оценка: +1 -5 :)))
L>>До сих пор нужно писать внешний цикл при сравнении строк? Нельзя загрузить в процессор адреса нуль-терминированных строк, выполнить одну команду и получить результат?
B>До сих пор не используешь Unicode для своих строк? А то в них нулевой байт может появиться в самом неожиданном месте.
UTF16/32 не нужны
Как много веселых ребят, и все делают велосипед...
Re[2]: Команды сравнение строк в ассемблере нет?
От: nekocoder США  
Дата: 18.11.19 19:40
Оценка: +1
Здравствуйте, bzig, Вы писали:

B>До сих пор не используешь Unicode для своих строк? А то в них нулевой байт может появиться в самом неожиданном месте.


В UTF-8 не может
Re: Команды сравнение строк в ассемблере нет?
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 18.11.19 19:42
Оценка: +2
Здравствуйте, lamai, Вы писали:


L>repe cmpsb

L>До сих пор нужно писать внешний цикл при сравнении строк? Нельзя загрузить в процессор адреса нуль-терминированных строк, выполнить одну команду и получить результат?

А где тут был _внешний_ цикл?
The God is real, unless declared integer.
Re[3]: Команды сравнение строк в ассемблере нет?
От: bzig  
Дата: 18.11.19 20:05
Оценка: -3
Здравствуйте, nekocoder, Вы писали:

N>Здравствуйте, bzig, Вы писали:


B>>До сих пор не используешь Unicode для своих строк? А то в них нулевой байт может появиться в самом неожиданном месте.


N>В UTF-8 не может


Чойта? В Юникоде 0x0 — просто NUL символ, он может быть в составе Юникодной строки сколько угодно раз, он не означает конец строки или что-либо ещё.
Re[4]: Команды сравнение строк в ассемблере нет?
От: lamai  
Дата: 18.11.19 21:48
Оценка:
Здравствуйте, bzig, Вы писали:


N>>В UTF-8 не может


B>Чойта? В Юникоде 0x0 — просто NUL символ, он может быть в составе Юникодной строки сколько угодно раз, он не означает конец строки или что-либо ещё.


UTF-8 совместим со старым софтом и протоколами, потому что в такой строке не может встретиться байт 0x00, который бы ее обрывал.

Re[5]: Команды сравнение строк в ассемблере нет?
От: bzig  
Дата: 18.11.19 22:36
Оценка: +1
L>

L>UTF-8 совместим со старым софтом и протоколами, потому что в такой строке не может встретиться байт 0x00, который бы ее обрывал.


у вас ссылка отклеилась
Re[5]: Команды сравнение строк в ассемблере нет?
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 19.11.19 07:13
Оценка: 2 (2) +5 -1
Здравствуйте, lamai, Вы писали:

B>>Чойта? В Юникоде 0x0 — просто NUL символ, он может быть в составе Юникодной строки сколько угодно раз, он не означает конец строки или что-либо ещё.


L>UTF-8 совместим со старым софтом и протоколами, потому что в такой строке не может встретиться байт 0x00, который бы ее обрывал.


Ни в "старом софте и протоколах", ни в новых нет никакого обязательного правила, что NUL не может встречаться в теле текстовой строки. Это абсолютно рядовой управляющий символ. Если считаете иначе — покажите соответствующий стандарт среди тех же издателей, что выдали ASCII с компанией, то есть ECMA, ISO, IEC. Вангую: ничего такого не найдёте.

Особая роль кода 0 является специфическим дополнением API Unix и родственных систем. И в Unix оно не является универсальным: большинство современных утилит, работающих с текстами (как sed, awk, sort, редакторы типа vim) адаптированы на поддержку NUL как обычного кода. POSIX хранит разрешение на ограничение "NUL не может быть в текстовой строке" для легаси, но не запрещает расширять реализации на его поддержку. Большинство утилит GNU (типа sed, awk, sort), средств скриптования вроде Perl, Python не запрещают NUL в строках или текстовом вводе-выводе.

В C++ основным средством представления текста является std::string, которая явно хранит длину данных и не запрещает NUL в них. Все интерфейсы адаптированы на использование длины там, где она известна. Начиная с C++17 есть std::string_view, который помогает обеспечивать то же самое для строковых литералов. Использование интерфейсов libc, которые вместо явной длины строки ищут NUL, ограничено относительно короткими строками, страдает проблемами маляра Шлёмиэля и в современных рекомендациях исключается, кроме тех мест, где длина строки неизвестна из-за свойств её источника.

Тенденция к отказу от API с NUL-terminated строками является известным свойством последних 30 лет, если не больше. Где вы провели всё это время — непонятно, но пора выползать из таёжного схрона.
The God is real, unless declared integer.
Re[4]: Команды сравнение строк в ассемблере нет?
От: ononim  
Дата: 19.11.19 07:32
Оценка: +1 :)
N>>В UTF-8 не может
B>Чойта? В Юникоде 0x0 — просто NUL символ, он может быть в составе Юникодной строки сколько угодно раз, он не означает конец строки или что-либо ещё.
не может, а еще слэш не может (за исключением когда слэш — это слэш) и много чего еще. Благодаря чему ядро лялиха поддерживает UTF8 в файловых системах даже не задумываясь об этом (в отличии от ядра винды, которая case insensitive и потому всегда думает над UTF16).
Какие байты могут быть в UTF8 строки написано тут https://en.wikipedia.org/wiki/UTF-8#Description — у всех многобайтных последовательностей установлен как минимум старший бит в каждом байте. А однобайтные символы — это ASCII
Как много веселых ребят, и все делают велосипед...
Отредактировано 19.11.2019 7:34 ononim . Предыдущая версия . Еще …
Отредактировано 19.11.2019 7:34 ononim . Предыдущая версия .
Re: Команды сравнение строк в ассемблере нет?
От: mike_rs Россия  
Дата: 19.11.19 07:41
Оценка:
Здравствуйте, lamai, Вы писали:


L>

L>xor eax,eax ;флаг результата. Если 0 — строки НЕ равны
L>mov esi,offset string1
L>mov edi,offset string2
L>repe cmpsb
L>jne done
L>inc eax ;флаг результата = 1, строки равны
L>done:
L>;если Eax = 0 — строки не равны, если 1 — равны.


L>До сих пор нужно писать внешний цикл при сравнении строк? Нельзя загрузить в процессор адреса нуль-терминированных строк, выполнить одну команду и получить результат?

а где в твоем примере цикл ? Ты именно что выполняешь одну команду (cmpsb) и получаешь результат (zf).
Re[6]: Команды сравнение строк в ассемблере нет?
От: night beast СССР  
Дата: 19.11.19 07:45
Оценка:
Здравствуйте, netch80, Вы писали:


N>В C++ основным средством представления текста является std::string, которая явно хранит длину данных и не запрещает NUL в них. Все интерфейсы адаптированы на использование длины там, где она известна. Начиная с C++17 есть std::string_view, который помогает обеспечивать то же самое для строковых литералов.


это не отменяет факта наличия функции std::string::c_str

N>Тенденция к отказу от API с NUL-terminated строками является известным свойством последних 30 лет, если не больше. Где вы провели всё это время — непонятно, но пора выползать из таёжного схрона.


хз. сишные API как-то не часто кроме чаров еще и длину (не как капасити) принимают
Re: Команды сравнение строк в ассемблере нет?
От: MasterZiv СССР  
Дата: 19.11.19 08:03
Оценка:
Здравствуйте, lamai, Вы писали:

Смотря какие строки, смотря какой процессор ...
Re[5]: Команды сравнение строк в ассемблере нет?
От: Mamut Швеция http://dmitriid.com
Дата: 19.11.19 08:12
Оценка:
B>>Чойта? В Юникоде 0x0 — просто NUL символ, он может быть в составе Юникодной строки сколько угодно раз, он не означает конец строки или что-либо ещё.
O>не может,

может

O>а еще слэш не может (за исключением когда слэш — это слэш) и много чего еще.


шта

O>Благодаря чему ядро лялиха поддерживает UTF8 в файловых системах даже не задумываясь об этом


еще как задумываясь

O>(в отличии от ядра винды, которая case insensitive и потому всегда думает над UTF16).


В винде проблемы не из-за этого.

O>Какие байты могут быть в UTF8 строки написано тут https://en.wikipedia.org/wiki/UTF-8#Description — у всех многобайтных последовательностей установлен как минимум старший бит в каждом байте. А однобайтные символы — это ASCII


0x0 — это тоже однобайтный символ. И в валидной UTF-8 последовательности он может быть в любом месте. Поэтому некоторые системы используют модифицированный UTF-8, чтобы избежать собственных ограничений, что является security-risk'ом и об этом напрямую говорится в RFC 3629


dmitriid.comGitHubLinkedIn
Re[6]: Команды сравнение строк в ассемблере нет?
От: ononim  
Дата: 19.11.19 08:14
Оценка:
M>0x0 — это тоже однобайтный символ.
вот именно, однобайтный символ из сабсета символов, эквивалентных ASCII.
Как много веселых ребят, и все делают велосипед...
Re[7]: Команды сравнение строк в ассемблере нет?
От: Mamut Швеция http://dmitriid.com
Дата: 19.11.19 08:18
Оценка:
M>>0x0 — это тоже однобайтный символ.
O>вот именно, однобайтный символ из сабсета символов, эквивалентных ASCII.

Еще раз. Медленно:

В Юникоде 0x0 — просто NUL символ, он может быть в составе Юникодной строки сколько угодно раз, он не означает конец строки или что-либо ещё.


И это справедливо для UTF-8 тоже. Просто в кодировке UTF-8 (одной из возможных кодировок):

Character numbers from U+0000 to U+007F (US-ASCII repertoire)
correspond to octets 00 to 7F (7 bit US-ASCII values). A direct
consequence is that a plain ASCII string is also a valid UTF-8
string.


То есть:

— plain ASCII string является валидной строкой в UTF-8
— обратное неверно в общем случае


dmitriid.comGitHubLinkedIn
Re[8]: Команды сравнение строк в ассемблере нет?
От: ononim  
Дата: 19.11.19 08:21
Оценка:
M>В Юникоде 0x0 — просто NUL символ, он может быть в составе Юникодной строки сколько угодно раз, он не означает конец строки или что-либо ещё.
Ну, покажи как выглядит этот NUL символ в печати и к какой локали он соответствует? Так то и в ASCII 0 — это просто NUL символ. Но он никому не нужен ни для чего, кроме как индицировать конец строки. Точно так же и в юникод строках. Хотя либители паскаля и UNICODE_STRING могут хранить в нем соленые огурчики, конечно)
Как много веселых ребят, и все делают велосипед...
Отредактировано 19.11.2019 8:23 ononim . Предыдущая версия .
Re[9]: Команды сравнение строк в ассемблере нет?
От: Mamut Швеция http://dmitriid.com
Дата: 19.11.19 08:28
Оценка: +4
O>Ну, покажи как выглядит этот NUL символ в печати и к какой локали он соответствует?

юникод не имеет отношения к печати

O>Так то и в ASCII 0 — это просто NUL символ. Но он никому не нужен ни для чего, кроме как индицировать конец строки.


В ASCII и в системах с null-terminated строками — да. Но:

— строки не обязательно должны быть null-terminated
— NUL не означает завершение строки в юникоде
— юникодная строка является валидной даже если NUL встречается в ней в середине
— это справедливо для всех юникодных кодировок, включая UTF-8

Поэтому некоторые системы используют модифицированный UTF-8, чтобы избежать собственных ограничений, что является security-risk'ом и об этом напрямую говорится в RFC 3629.

С чем ты споришь, непонятно.


dmitriid.comGitHubLinkedIn
Re[10]: Команды сравнение строк в ассемблере нет?
От: ononim  
Дата: 19.11.19 08:36
Оценка: +4
Еще раз: в ASCII символ с кодом 0 — это просто null символ: http://www.asciitable.com/
И в середине ASCII строки символ с кодом 0 тоже может быть, ктож помешает
То что строки в C являются NULL-terminated — это соглашение на уровне ЯП, а не на уровне кодировки.
NULL-terminated строки в кодировке ASCII. NULL-terminated строки в кодировке KOI8. NULL-terminated строки в кодировке CP1251. Точно так же может быть NULL-terminated в кодировке UTF8/UTF16/UTF32. За небольшим дополнением что размер codepoint unit в UTF8 равен 1, а в UTF16 — два, а в UTF32 — четыре. И потому NULL-character в UTF8 — это просто байт 0, как и в "простых" однобайтных кодировках. А в UTF16 — это два байта 0 (на четной позиции). А в UTF32 — четыре нулевых байта.
В свою очередь алгоритм кодирования многобайтных символов в UTF8 устроен так, что ни один многобайтный символ не может содержать в себе нулевой байт. А значит нулевой байт в UTF8 однозначно является NUL character'ом. В отличии от UTF16/32 где NUL character'ом является лишь нулевой codepoint unit, а нулевые байты могут быть частью ненулевых codepoint unit-ов.
Как много веселых ребят, и все делают велосипед...
Отредактировано 19.11.2019 8:41 ononim . Предыдущая версия . Еще …
Отредактировано 19.11.2019 8:41 ononim . Предыдущая версия .
Отредактировано 19.11.2019 8:37 ononim . Предыдущая версия .
Отредактировано 19.11.2019 8:37 ononim . Предыдущая версия .
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.