Switch в masm

Товарищи знатоки есть ли в синтаксисе MASM аналоги сишных switch/case ? Подкиньте пищу для ума, если честно не особо хочется загромождать код структурами с адресами и инструкциями типа jmp dword ptr:[ecx+eax*4+offset blablalba]

 

можно через конструкцию ELSEIF

 

А если числа идут подряд, то можно через

Код (Text):

1. dec reg
2. jz xx
3. dec reg
4. jz xx
5. dec reg
6. jz xx
7. ...

О макросах в таком стиле я не слышал, хотя они наверняка есть

 

не порите чушь. ей это уже давным двно не нравится. это наверное самая быстрая реализация switch, а Вы хотите сделать глупость только от того, что Вам это не нравится!

 

max7C4
если в его проге этот участок далеко не самое узкое место, то использование
ELSEIF для простоты понимания вполне оправдано

 

wsd
ага. а можно не на макросах, а по нормальному

Код (Text):

1. cmp ...
2. jcc ...
3. ...
4. jmp ...

 

max7C4

да, быстрая.
но ещё быстрее когда сравнения расположены по порядку, по статистике появления значения. т.е. чем вероятнее появления значения, тем раньше на него проверять

 

Быстрая это бинарное дерево.

 

Booster
это смотря как статистика выглядит
к утрированному примеру A-90% B-5% C-5% , быстрее статически чем бинарпое деревро будет. а если 20 значений с вероятностью в 5%, то да, бинарное дерево

 

wsd
Стоит ли игра свеч, если всего несколько вариантов перехода? Статистика конечно здорово, но по-моему это смахивает на задротство. Думаю лучше это оставить на откуп блоку предсказаний процессора.

 

Booster wsd
вы в своем уме. куча кода против одной инструкции, тем более которую процессоры уже научились предсказывать, если она исполнялась более одного раза.
Booster
вот никогда не поверь, что бинарное дерево обгонит jmp dword [eax*4+ebx]
в худшем случае тут процессор потеряет несколько тактов в случае промаха, в вашем же случае будет куча ложных предсказаний т.к. система повязана на условные прыжки назад, а длина кода и много поточность вычистят динамическую систему предсказания условных переходов. эту инструкцию наверное стоит поставить только одной альтернативе

Код (Text):

1. test eax, eax ; установка флагов
2. jnz @f                   ; промах в случае перехода
3. ...
4. jmp .quit                ; относительный переход
5. @@:
6. ...
7. .quit:
8.  
9. ;1 случай)
10. ;test/нет промаха/jmp
11. ;эти инструкции вполне равносильны по времени call dword [eax*4+ebx]/ret
12.  
13. ;2 случай)
14. ;test/промах
15. ;эти инструкции загонят проц в больший ступор чем jmp [eax*4+ebx]/jmp rel32

и то как мы видим в данной конструкции процессор потеряет примерно столько же времени что и при jmp.

 

max7C4
Я не писал, что бинарное дерево самое быстрое.

 

Booster
да извините ткнул не туда. вторая часть к wsd

 

Booster

а я писал про частный случай
max7C4
кстати у твоего метода есть существенные ограничения по сравнению с моим и Booster
при сильной разнородности значений представляеш как это будет с точки зрения использования памяти под таблицы? т.е. допустим значения будут такие 1; 10;100; 1000; 10000; 100000 . представляеш как будет выглядеть таблица индексов? что будет между
ними ? это конечно редкий случай, но всё же

 

wsd

Ничего особенного не будет. Делаешь нормированный хэш из этих чисел и таблицу. Коллизии обрабатываются так же.

Сам так делал - особенно эффективно для строковых аргументов.

 

PSR1257

дай кода?

 

PSR1257

Угу особенно для больших строк, где поиск быстрее вычисления хеша. Это тоже далеко не панацея. Проверял hash_map, что-то не впечатлило.

 

PSR1257
+1
Booster
а хеш можно сделать частичный

 

max7C4
Не панацея, пока будешь считать хеш(даже небольшой), то да сё, всё равно очень велика вероятность, что дерево будет быстрее. Да и хеш таблица не резиновая.

 

Booster
это все переходит уже на стадию философствования о том, чья коровы красивее. если составлять бин.дерево, то ограничиваться размерами, или количеством уровней, если использовать jmp [eax*4+ebx], то ограничиваться количеством ссылок в таблице, а если использовать хеш, то длинной и временем подсчета. в любом случае идеального метода не найти