Алгоритм - поиска и парсинга

J0E

бизнес-логика на FASM

 

и вообще наверное все олгоритмы обработки данных

 

включите правку!
а то kero опять на безграмотность ругаться начнёт

 

речь шла не о языке ассемблере x86, а об исходном коде ассемблера.

 

Речь шла о разработке кода на языке ассемблера (мультиплатформа под win32/64, like *nix)
После небольшого изучения парка всевозможных, на данный момент я скланяюсь к YASM за что большой респект DEADHUNT )

Есть правда два неудобства в работе с YASM (лично для меня), то что нужно на него переучиваться с MASM-a и IDE RadASM с ним не живет, в остальном все супер.

Теперь наступила фаза номер 2 - нахождение оптимальных алгоритмов контекстного поиска и структурирования словаря.

Если кто делал что-то подобное на асме, буду благодарен за инфу, а еще больше за сырцы)

 

Интересно увидеть код на языке ассемблера, который можно компелировать как 32 так и 64 бита. Без сложной бизнес-логики, парсинга строк хватит

 

Код (Text):

1. _main:
2. ifdef _BITS64
3. push rbp
4. mov rbp, rsp
5. sub rsp, 0x100
6. else
7. mov ebp
8. mov ebp, esp
9. sub esp, 0x100
10. endif
11. ....
12. leave
13. ret

 

* push ebp

 

DEADHUNT

лучше так:

Код (Text):

1. ifdef _BITS64
2.     a_bp equ rbp
3.     a_sp equ rsp
4. else
5.     a_bp equ ebp
6.     a_sp equ esp
7. endif
8.  
9. _main:
10. mov a_bp
11. mov a_bp, a_sp
12. sub a_sp, 0x100
13. ....
14. leave
15. ret

 

Да..... но скорее будет sub a_sp, 0x40 * sizeof_pointer
Добавим передачу параметров в функцию? До алгоритма доберёмся через недельку.

 

у нас что в стеке только 0x40 указателей? просто надо ещё rsp выравнить тоесть

Код (Text):

1. sub a_sp, (0xXXXX + ptr_size - 1) & ~(ptr_size - 1)

 

Собственно проще и быстрее сделать 2 ветки кода под 32 и 64 битные процы.
Благо алгоритм один и тотже))

 

Ребята у вас все впорядке с логикой? Неужели проще писать и тестировать код 2 раза, поиметь головняк с синхронной поддержкой веток, а не раз и навсегда сделать на С или С++? Где доступно и PCRE, и генераторы парсеров. Я тоже очень люблю асм, но поймите что написание кода максимум 20% работы, остальные 80 это его поддержка.

 

J0E!

С логикой как раз все в порядке, поскольку перед разработкой приложения я взвешиваю множество плюсов/минусов языков, технологий, алгоритмов ...
Почему рассматриваю асм, да потому что нравится он мне и я считаю его максимально производительным языком при задачах поиска и парсинга.

Вот скажи добрый человек, откидывая алгоритмы, методы и прочие умные вещи, какая разница будет в производительности идентичной задачи написанной на ASM vs C (С++ откинем)?

 

ATX

Нравится и пользую, на первом месте. Это главный приоритет. Не думаю что си сколько-нибудь существенно отстаёт в задачах поиска и парсинга. Вот если-бы там была хитрая обработка, тогда другое дело.

 

Booster
А что ты называешь хитрым алгоритмом, поиск знаеш ли тоже отнуюдь не простая задача, тем более по словарю.
Тут куча алгоритмов поиска, есть над чем подумать.
А касаемто реализации на С, думаю в этом вопросе он всеже на много порядков произрывает асму.

 

Много это сколько? Три - это много? А четыре ?
3 порядка - это в 1000 раз.

 

Похоже ты прикалываешься. Никакой. В задаче поиска обычно говорят "а как мне получить сложность лучше логарифмической на таких-то данных?", читают про деревья, minimal perfect hash. Потом, если и пишут, то ГЕНЕРАТОР исходника парсера. Руками на асме я как-то убил пару месяцев, вот и не советую =)

 

ATX

Сравнение со всех сторон не корректно
Во первых низкоуроневая оптимизированность С/С++ кода определется способностями компилятора, а он для С и С++ один и тот же , во вторых очень многое зависит от программиста, если он знает асм, то способен структурировать С/С++ код так что он скомпилится в нечто очень похожее на качественно написанное вручную на асме, но это естественно не повод надеяться что любой код будет автоматически качественно оптимизироваться - знать и чуствовать асм нужно, но это ещё не повод категорически отказваться от С а тем более от С++ дающего массу удобств не связанных с низкоуровневой оптимизацией. В третьих не стоит надеятся что код будет быстр просто от того что он написан на асме, там тоже много тонкостей очень сильно влияющих на результат, да и времена непроходимой тупости оптимизирующих компиляторов в общем-то прошли

И как верно заметил J0E алгоритмическая оптимизация в подавляющем большинстве лучаев даёт куда больший эффект чем низкоуровневая, потому правильно сначала максимально оптимизировать алгоритм, а у же потом "ловить блох" - это тоже увлекательно и полезно, но это уже "окончательная шлифовка и полировка", а не "главный двигатель программы" )

 

да в принципе переточить тотже коко, чтоб он на выходе давал текст на асм (масм, фасм, насм, васм итд) можно. примеры генераторов для разных языков имеются. вот только зачем? одной только мудистики с регистрами хватит, а в компилерах/вм полно работы с хэшами, списками, деревьями и прочей мути. их ведь тоже на асм переносить надо будет. ну и непереносимость.. впрчем, если вы так хотите воспользоваться некоторыми выигрышными особенностями асма, то асм вставки и отдельно прокомпиленые асм модули еще никто не отменял, а от скорость и размеры синтаксического парсера и генератора первичного п-кода мало на что влияют. в конечном продукте они < 1% (промежуточный C)