-
всем сдрасти пример функции function CompStr(const S1, S2: string): Integer;
asm
TEST EAX,EAX
JE @@2
TEST EDX,EDX
JE @@3
PUSH EAX
MOVZX EAX,BYTE PTR [EAX]
MOVZX ECX,BYTE PTR [EDX]
SUB EAX,ECX
JE @@m
POP ECX
RET
@@m: POP EAX
INC EAX
INC EDX
@@0: TEST CL,CL
JE @@5
MOV CL,BYTE PTR [EAX]
MOV CH,BYTE PTR [EDX]
CMP CL,CH
JNE @@ne
TEST CL,CL
JE @@5
MOV CL,BYTE PTR [EAX+1]
MOV CH,BYTE PTR [EDX+1]
CMP CL,CH
JNE @@ne
TEST CL,CL
JE @@5
MOV CL,BYTE PTR [EAX+2]
MOV CH,BYTE PTR [EDX+2]
CMP CL,CH
JNE @@ne
TEST CL,CL
JE @@5
MOV CL,BYTE PTR [EAX+3]
MOV CH,BYTE PTR [EDX+3]
ADD EAX,4
ADD EDX,4
CMP CL,CH
JE @@0
@@ne: MOVZX EAX,CL
MOVZX EDX,CH
SUB EAX,EDX
RET
@@2: TEST EDX,EDX
JE @@7
MOV CH,BYTE PTR [EDX]
TEST CH,CH
JE @@7
NOT EAX
RET
@@3: MOV CL,BYTE PTR [EAX]
TEST CL,CL
JE @@5
MOV EAX,1
RET
@@5: XOR EAX,EAX
@@7:
end; очевидно х32 + AnsiString вопрос, можно ли без переработки самого алгоритма сделать ее для 1)Unicode просто заменой типов шага или чего то там 2)x64 просто заменой каких то команд\регистров х32 на х64 з.ы. в асме не понимаю ничего
-
Сравнение юникодных строк - это много больше, чем побайтовое сравнение.
-
-
> Kerk © (02.11.17 12:36) [1]
дану нафиг и чем же больше? мне интересна прокачка кода, а не то правильно это или нет, в паскале это была б просто замена типов и проверки длин
-
> QAZ © (02.11.17 14:44) [3] > дану нафиг и чем же больше?
Ну например буква å может храниться в строке как один символ, либо как комбинация 2 символов: кружочек + a. Для пользователя это выглядит одинаково, но побайтово это разные строки. Поэтому строки перед сравнением нормализуют.
> мне интересна прокачка кода, а не то правильно это или нет, > в паскале это была б просто замена типов и проверки длин
Тогда даже ничего переделывать не надо. Сравнивай побайтово как раньше.
-
> Тогда даже ничего переделывать не надо. Сравнивай побайтово > как раньше.
ненене, так не пойдет во первых эта функция просто пример, речь идет обо всем написанном за десятилетия коде во вторых зачем мне лишние компиляторские автоконверсии уникод\анси в третьих че там с х64?
-
Какие еще автоконверсии в ассемблере?
-
> Kerk © (02.11.17 16:35) [6]
вот прям вот здесь function CompStr(const S1, S2: string): Integer
-
Возьмите современный компилятор. Там всё есть.
-
1) В ассемблере нет информации о типах данных и восстановить их невозможно. 2) Разработка хорошие тесты по времени занимают 1٫5-2 раза от разработки кода. Так что их по любому писать и они будут разными для разных версий x86 x86-64. А ещё вы хотите поддерживать Ansi и Unicode. Всё это разные работы и должны оплачиваться отдельно. 3) Экономически выгоднее купить готовое чем разрабатывать самому.
-
> 1) В ассемблере нет информации о типах данных и восстановить их невозможно.
а это что тогда ? MOV CL,BYTE PTR [EAX+3]
-
конечно, это boolean )
-
> а это что тогда ?
Это приведение размера данных. Который к тому же в fasm запросто может отсутствовать.
-
> Это приведение размера данных.
вот я и спрашиваю, можно ли просто меняя эти приведения с BYTE на WORD или там с CHAR на WCHAR с еще чем-то перевести на уникод для начала
> Который к тому же в fasm запросто может отсутствовать
щаз бы на форуме про делфи, в теме о встроенном асме вспоминать про fasm...
-
> [13] QAZ © (03.11.17 10:53) > вот я и спрашиваю, можно ли просто меняя эти приведения > с BYTE на WORD
Нельзя. Надо разбирать логику работы, в каких регистрах и когда что там хранится. Это не говоря про Юникод, про который уже сказали, но ты всё-таки про 2-байтовую кодировку имел ввиду.
-
ну нельзя так нельзя
-
А строку в анси и на вход никак низя? Сам же сказал шо база наработана, знач раньше все устраивало
-
> Rouse_ © (04.11.17 00:55) [16]
например если конкретно эту функцию использовать в квиксорте, то за счет этих конверсий скорость упадет в 1000+ раз да и конверсия туда обратно будет с потерями символов
з.ы. у меня нет проблем, я спрашиваю гипотетически-теоретически кроме того х32 за счет повсеместного юза асамблерных вставок работает быстрей х64 и будет работать быстрей ближайшие годы несмотря на виртуализации и прочее
-
> Rouse_ © (04.11.17 00:55) [16]
в догонку прям вот сейчас в 2017г есть куча софта, включая игры ААА класса которые не работают нормально(не работает сохранение настроек и тд) из-за того что профиль юзера содержит не латинские символы в названии т.е. вместо C:\Users\Вася\AppData\Roaming они видят C:\Users\????\AppData\Roaming, как думаешь это нормально? не говоря уже об интерфейсе с кракозябрами т.е. разрабы не то что не вкурсе про уникод, они даже не вкурсе существования языков отличных от английского
|