Алгоритмический ассемблер

Язык ФОРТ вроде так и устроен, или я путаю?
Или Ц с передачей параметров функциям в регистрах.

 

Тем более, что эта прога под венду. А я на венду клал большой и толстый.

 

SadKo

Класть-то можно, но большинство всё равно на ней сидят :-P

 

Что-то похожее на этот AlgorithmBuilder я сделал однажды (1994). Много проблем, например, оптимизировать код неудобно - всё таки ассемблерный листинг легче оптимизировать, чем разбросанные по поверхности блоки. Сложно подвести ООП под это дело. Для каких-то небольших проектов - может быть...

 

Но не я.

 

Так код как раз вней удобно оптимизировать. Вы же видете как у Вас циклы и ветви организованы а циклы это главный козырь при оптимизации. Например чикл с декрементом выполняется быстрее чем цикл с инкрементом.
При том всегда можно будет посмотреть ассемблерный листинг и если что поправить ручками.

Да если не сложно можно посмотреть на вашу программу.

 

До эмиграции это было... не сохранилась программа.

В общем, аппликация (Windows 3.11) состояла из простого окна с координатной сеткой. На сетке можно было создавать такие объекты:

1. Начало функции (графически как прямоугольник с полусферами слева и справа)
2. Конец функции (та же форма, но с другим цветом фона)
3. IF() элемент (графически как прямоугольник с треугольниками слева и справа)
4. Элемент кода (простой прямоугольник)
5. Элемент метка (в форме ромба малого размера)

Все элементы имели места для входов/выходов - помечены ромбами (меньшего размера чем МЕТКА и другого цвета), таким образом было легко видеть где надо проводить линии соединений.

Ну и далее мышью проводим линии и готов алгоритм. Каждый элемент имел определённый текст, участвующий в генерации кода (TASM). В одном файле (модуле) можно было хранить несколько алгоритмов.

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

В общем, интересная игрушка, но бесполезная.

 

Да здесь есть этот недостаток особенно когда функция имеет очень длинный алгоритм приходится постаянно крутить скорлинг.

Как переход не предсказан по умолчанию. Переход или есть или нет, у нас же не нечеткая логика.

Очень жаль что у Вас не сохранилась эта программа.
А так бы хотел на нее взглянуть.
А Вы бы нихотели востановить свою программу в более современном виде.
Может я бы смог чем нибудь помочь. А так в облом одному писать программу с нуля, а у Вас есть уже опыт.

 

Если появится время, можно попробовать. Я занят пока ООП ассемблером.

О предсказании переходов (на русском не нашёл):
http://en.wikipedia.org/wiki/Branch_prediction

Процессор "смотрит" вперёд на несколько инструкций и если есть условный переход, то блок предсказания переходов решает надо-ли подгружать комманды в поток инструкций начиная с адреса перехода. Если переход будет и инструкции не подгружены - теряем скорость естественно (надо время на загрузку). То же верно и в обратном отношении: если подгрузили инструкции а перехода нет, надо возвращать инструкции со старого места - опять теряем.

Переход назад всегда предсказан. Хорошо для циклов.

Если адрес перехода впереди, то такой переход не предсказан, это значит что инструкции с этого адреса не будут загружены несколько раз. Но если блок предсказания "видит" что переход на этот адрес произошёл несколько раз подряд, тогда считается что последующие переходы предсказаны.

В общем, сложная штука.

Поэтому при написании оптимального кода, переходы вперёд должны делаться статистически не часто. Пример: есть функция, которая должна проверить входные параметры на правильность:

Код (Text):

1. ; ----------------------------------------------------------
2. ;
3. ; Code Fragment #1
4. ;
5. ; Checking parameters:
6. ;
7. ;   EAX must be greater than 2
8. ;   EDX must not be NULL
9. ;
10. ; ----------------------------------------------------------
11.     cmp eax, 2
12.     jg  .next_chk   ; EAX OK. Check EDX now.
13.     ret         ; Bad EAX! Get out!
14.  
15. .next_chk:
16.     test    edx, edx
17.     jnz .all_good       ; EDX OK - function can execute
18.     ret         ; Bad EDX! Get out!
19.  
20. .all_good:
21.     ... ; Function continues...
22.  
23.     ret
24. ; ----------------------------------------------------------
25. ;
26. ; Code Fragment #2
27. ;
28. ; Checking parameters:
29. ;
30. ;   EAX must be greater than 2
31. ;   EDX must not be NULL
32. ;
33. ; ----------------------------------------------------------
34.     cmp eax, 2
35.     jle .failed
36.  
37.     test    edx, edx
38.     jz  .failed
39.  
40.     ; function can execute
41.  
42.     ret
43.  
44. .failed:
45.     ; diagnostics
46.     ret

Какая ситуация встретится чаще? Правильные параметры или неправильные? По логике вещей - правильные. Это значит, что (при правильных параметрах) переходить вперёд чаще будет код #1 (два прыжка при вызове функции). Код #2 (при правильных параметрах) будет просто "проваливаться" на следующие инструкции. Переходы произойдут при неправильных параметрах. Код #2 быстрее (теоретически, конечно ).

В этом есть ещё интересные вещи. Например: переход вперёд может быть настолько короткий, что инструкции могут уже быть загружены, потому что кэш инструкций имеет определённый размер. Или (в коде #2) инструкция выхода по ошибке (.failed может оказаться дальше чем 128 байт. Это вызовет необходимость новых переходов.

 

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

Я забросил эту оптимизацию так как она напрямую зависит от архитектуры процессора и прощитать это просто невозможно. Но иногда ее приминяю в других процессорах где можно просчитать все до такта (RISC) и где есть описание архитектуры процессора. А так как мы не знаем что в нашем пенке то смысл ее отподае. Пишите как нравится.

 

А у меня была идея вообще написать новый язык. А то Си меня уже бесит просто. Асм сдает позиции и не для всех прост.

 

Хотя используя макросы можно и асм переработать

 

Ваши предложения конкретно. Каким вы видите новый язык?

C уже ~35 лет и еще через 35 лет он будет актуален. Решетку же забудут как забывают счас MFC.

Асм может сдать позиции только с исчезновением данного проца.
Учитывая, что источником успеха x86 является совместимость по асму и архитектуре. Интел разорвется но сохранит ему жизнь.

Ну а простоты для всех не достичь в принципе. Некоторым и по русски едва два слова связать могут. Може и тут обкорнаем?

 

Асм самый простой язык.
Он на порядок проще чем С и С++.
Единственное он плохопонимаем на мнемоническом уровне (хотя развивает абстрактное мышление).
Поэтому его надо привести в божеский вид что бы он радовал глаз.
Не мнемоники читать а условные графические изображения видеть.
Мнемоники пошли когда небыло графических компьютеров а был только текстовый экран.

 

В принципе, можно поставить каждой команде процессора графический эквивалент, например:

Код (Text):

1. [register/memory] [instruction icon] [register/memory]

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

 

Мои пять копеек.

Любопытно какие картинки для каждой команды х686 проца +FPU, +ММХ-ы и +SSE-ы ваша фантазия вам поскажет.

Придумывая на каждом уровне новые сотни различных картинок.

Наверное. А потом пропускать через автоматический оптимизатор, который прибьет 70% лишних инструкций и его тоже нарисовать на картинках.
Маленький пример: парсер и кодогенератор openwatcom С (ANSI-C) занимают около 150Кб, а оптимизатор > 700Кб

 

Нарисовать можно любые картинки лишбы они отражали суть процесса проходящего в команде.
Ну например mov BX,AX можно заменить на AX->BX и.т.д.

Так это же С оптимизатор на асме не чего лишнего нет.

 

при такой замене зачем вам картинки? Это тот-же асм, только вид сбоку. Берете какой-нибудь coco и пишете в нем замену ваших операторов на операторы скажем fasm-a с выдачей результата, например, на стдоут.

Я-бы так не говорил. И масм и фасм проводят неявную оптимизацию по размеру. Причем фасм - лучше, он очень хорошо оптимизирует переходы. Кроме того, я-бы не отказался от пусть полуавтоматического, но оптимизатора развертывания макросов. Кроме того, я-бы не отказался от препрепроцессора по типу латексовского. А все высокоуровневые инструкции от МС пусть идут лесом.

 

Как компилятор может оптимизировать то что Вы написали на ассемблере.
Он же не знает что у Вас в голове а если он начнет своедумство (класное слово надо записать в блокнотик) то это уже не тот алгоритм который я писал.

Выкидывает ненужные переходы.8)
Как можно оптимизировать то что Вы написали а если он их оптимизирует не правельно и алгоритм весь на смарку.

Макрос это последовательность команд замененная одним словом (INVOCE [Label] это push push push....Call Label).
Как их сворачивать разворачивать можно тоже не понимаю.

Препроцессор это всего лишь дериктивы компилятора которые позволяют собирать код согласно условиям.

Оптимизировать можно только языки более высокого уровня так как все команды содержать стандартные блоки эти блоки постоянно оптимизируются выкидывая не нужные команды (например на стыке блоков у С можно заметить такие инструкции push AX push BX push CX pop CX pop BX pop AX) вот эти то команды оптимизатор и оптимизирует.

 

Маш код х86 дописывался в разное время и для разных целей. Таким образом в нем полно пересекающихся инструкций. Те ассемблерные инструкции могут быть переведены в различные машинные различающиеся и по длине, и по скорости выполнения процессором, и по изменяемым флагам. Оптимальность перевода асм мнемоника -> маш код, я и назвал оптимизацией. Ваш алгоритм его не интересует ни в асме, ни в С.

Процесс в котором 'одно слово' заменяется телом макроса и подстановкой его параметров называется развертыванием.

Объяснюсь. При развертывании макросов может возникнуть проблема с пересечением ресурсов (например изменяется регистр шибко используемый в основной проге). Возможна неоднозначность при подстановке параметров. Примеры:

Код (Text):

1. m1 macro a
2.   mov eax,a
3.   ...
4. endm
5.  
6. ...
7.  
8.   m1 eax
9. ...

такой код даст ненужную инструкцию mov eax,eax которую неплохо-бы опустить.

Код (Text):

1. _add macro a,b
2.   mov eax,a
3.   add eax,b
4. endm
5.  
6. ...
7.  
8.   _add 5,6
9.  
10. ...

опять получаем корявый код. Обычно эту проблему пытаются решить вручную. Обсуждений как это сделать полно и тут на форуме фасма. Уже из-за распрстраненности этой проблемы стоит задуматься об оптимизаторе развертывания макросов.

Опять цитирую себя. Объяснюсь. Тексовский (ошибся) препроцессор, на мой взгляд, дает наиболее мощные возможности по записи команды из всех, что я знаю. Он больше похож на лексер+парсер из компилера компилеров и при этом очень удобен и понятен. К примеру в латексе исходник пишут на макросах, которые потом препорцессируются в текс.

Оптимизировать можно все. Кроме того это гораздо более сложный процесс чем вы пишете.