из сарая
Итак, речь пойдет о таком великолепном языке, как ассемблер. Для начала давайте разберем, в чем же его великолепие?
1) Безграничные возможности. Подробнее:
2) Обширные возможности оптимизации. Только на ассемблере можно оптимизировать программу так, чтобы в ней не тратилось ни единого такта процессорного времени. Для этих целей есть возможность выравнивания массива в памяти, возможность управлять распределением команд на конвейеры (вру. Возможности нет. Но так как размер каждой команды известен заранее, то можно точно сказать, в какой конвейер пойдет одна команда, а в какой следующая). В том числе возможность оптимизировать занимаемую память - как под машинный код, так и под данные.
3) Обширные возможности создания программ. Ассемлер по сути язык императивный, но кто посмеет сказать, что этот язык не может поддерживать методологию ООП? Или что он не может быть функциональным? Или логическим? Все языки, абсолютно все языки программирования нужны лишь для того, чтобы упростить работу с ассемблером, но они не могут заменить его. Да, конечно, использование объектно-ориентированного (или тем более функционального) метода программирования на ассемблере весьма трудоемко. Точнее, этот процесс требует от программиста коллосального внимания, логики, памяти и т.д. Но тем не менее, тот факт, что никто не может и не хочет этого сделать еще не означает, что это невозможно.
4) Низкий уровень разработанных программ. Если есть в системе какое-то устройство и если оно правильно работает, то единсвтенный язык, который со 100% гарантией сможет работать с этим устройством - ассемблер. Собственно, вирусы (которые по сути являются маленькими иголками, способными проникнуть даже в самую маленькую дырочку, оставленную между огромными монолитами объектов, созданных другими, высокоуровневыми языками) в большинстве своем созданы на ассемблере (а остальные - на С++ с ассемблерными вставками) , потому как такие тонкости возможны только на нем.
А теперь о соответсвующих каждому вышеописанному пункту недостатках:
1) Безграничные сложности. Подробнее:
2) Обширные возможности оптимизации скромно ожидают своего гуру программирования, способного использовать все эти возможности. В отличие от автоматизированных компиляторов для высокоуровневых языков, ассемблерный интерпретатор не может оптимизировать код, если этого не сделал сам программист. Поэтому чтобы использовать все эти возможности, нужно для начала их знать и уметь ими пользоваться.
3) Обширным возможностям создания программ перекрывает кислород обширная сложность создания даже простых программ. Действие, которое в высокоуровневом языке занимает одну строку, в ассемблере может занимать целую страницу, в которой нужно будет точно расставить каждую команду. Объектно-ориентированный подход возможен, но на чистом ассемблере это будет выглядеть как обычный императивный код. Хотя, даже не императивный. Это будет просто сплошной поток кода и данных. Процедура в ассемблере - это просто абстрактный указатель на какое-то место в этом коде. А функциональный подход на чистом ассемблере вообще по сути невозможен (если брать в расчет такие возможности, как, например, ленивый код), точнее этот подход не будет иметь смысла, т.к. никакого упрощения программирования не выйдет.
4) Низкий уровень программ. Только низкий. Это означает, что программа аккуратно огибает все неровности архитектуры целевого компьютера. И программист должен подробно описать каждый такой изгиб на теле программы. А если это большая программа? Тогда только на перечисление всех этих "изгибов" и "неровностей" уйдет пару лет, не говоря уже о том, чтобы их подробно описать. Компиляторы высокоуровневых языков берут все это на себя, давая программисту возможность оперировать огромными частями программы с легкостью одной строчки.
А теперь "апогей" этой статейки - все эти недостатки могут быть бесследно стерты с истории ассемблера если в него просто добавить макросы. Разработка компилятора для ассемблера с хорошими макросами займет времени не больше, чем разработка какого-нибудь компилятора Visual C++, но вот результат будет гораздо лучше, т.к. язык, обладающий преимуществами и лишенный недостатков чистого ассемблера, - это величайший язык. Ведь если хорошо постараться с разработкой макросов, сделать их использование свободным, не стесняющим возможностей чистого ассемблера, то тогда вполне можно будет создать такой вот величайший язык. Было бы желание. Но почему-то у великих кампаний нет желания связываться с ассемблером, им проще списать его в число древних ископаемых, которые уже не способны сравниться с их могучими титанами С++, Object Pascal, Basic, Fortran, Lisp, Prolog, и т.д. и т.п. Собственно, ассемблер пытались списать со счетов с тех самых пор, когда в обиходе стали использоваться высокоуровневые языки (а это более двадцати лет назад), но безуспешно. FASM (Flat Assembler) - первая (известная мне) попытка реализовать такие макросы. Но этот ассемблер поддерживает (если поддерживает) всего-лишь один человек, соответственно несмотря на отличные, оригинальные и многофункциональные макросы, FASM все еще не может избавиться от своих недостатков, хотя и уменьшил их сравнительно с TASM, MASM или другими ассемблерами. К тому же у него нет хорошего IDE, т.к. Fresh - единственный более-менее удобный IDE - не может поравняться с современными интерфейсными монстрами.
Выводы из рассуждений: единственные две вещи, необходимые для того, чтобы на долгие и долгие годы возродить ассемблер и поднять его на несколько порядков выше высокоуровневых языков, это проработанный язык макросов и многофункциональный IDE. И эти две вещи не являются чем-то невозможным (ведь язык макросов едва ли будет сложнее, чем какой-нибудь язык С++, а уж IDE тем более легкая задача для таких матерых фирм, как Borland или мелкомягкие (впрочем, последние никогда не возьмутся за это, ведь у них же есть такой великолепный язык, как бейсик, компилятор для которого когда-то написал мальчик билли)). Но проблема в том, что все бояться ассемблера, как черт ладана.
1) Безграничные возможности. Подробнее:
2) Обширные возможности оптимизации. Только на ассемблере можно оптимизировать программу так, чтобы в ней не тратилось ни единого такта процессорного времени. Для этих целей есть возможность выравнивания массива в памяти, возможность управлять распределением команд на конвейеры (вру. Возможности нет. Но так как размер каждой команды известен заранее, то можно точно сказать, в какой конвейер пойдет одна команда, а в какой следующая). В том числе возможность оптимизировать занимаемую память - как под машинный код, так и под данные.
3) Обширные возможности создания программ. Ассемлер по сути язык императивный, но кто посмеет сказать, что этот язык не может поддерживать методологию ООП? Или что он не может быть функциональным? Или логическим? Все языки, абсолютно все языки программирования нужны лишь для того, чтобы упростить работу с ассемблером, но они не могут заменить его. Да, конечно, использование объектно-ориентированного (или тем более функционального) метода программирования на ассемблере весьма трудоемко. Точнее, этот процесс требует от программиста коллосального внимания, логики, памяти и т.д. Но тем не менее, тот факт, что никто не может и не хочет этого сделать еще не означает, что это невозможно.
4) Низкий уровень разработанных программ. Если есть в системе какое-то устройство и если оно правильно работает, то единсвтенный язык, который со 100% гарантией сможет работать с этим устройством - ассемблер. Собственно, вирусы (которые по сути являются маленькими иголками, способными проникнуть даже в самую маленькую дырочку, оставленную между огромными монолитами объектов, созданных другими, высокоуровневыми языками) в большинстве своем созданы на ассемблере (а остальные - на С++ с ассемблерными вставками) , потому как такие тонкости возможны только на нем.
А теперь о соответсвующих каждому вышеописанному пункту недостатках:
1) Безграничные сложности. Подробнее:
2) Обширные возможности оптимизации скромно ожидают своего гуру программирования, способного использовать все эти возможности. В отличие от автоматизированных компиляторов для высокоуровневых языков, ассемблерный интерпретатор не может оптимизировать код, если этого не сделал сам программист. Поэтому чтобы использовать все эти возможности, нужно для начала их знать и уметь ими пользоваться.
3) Обширным возможностям создания программ перекрывает кислород обширная сложность создания даже простых программ. Действие, которое в высокоуровневом языке занимает одну строку, в ассемблере может занимать целую страницу, в которой нужно будет точно расставить каждую команду. Объектно-ориентированный подход возможен, но на чистом ассемблере это будет выглядеть как обычный императивный код. Хотя, даже не императивный. Это будет просто сплошной поток кода и данных. Процедура в ассемблере - это просто абстрактный указатель на какое-то место в этом коде. А функциональный подход на чистом ассемблере вообще по сути невозможен (если брать в расчет такие возможности, как, например, ленивый код), точнее этот подход не будет иметь смысла, т.к. никакого упрощения программирования не выйдет.
4) Низкий уровень программ. Только низкий. Это означает, что программа аккуратно огибает все неровности архитектуры целевого компьютера. И программист должен подробно описать каждый такой изгиб на теле программы. А если это большая программа? Тогда только на перечисление всех этих "изгибов" и "неровностей" уйдет пару лет, не говоря уже о том, чтобы их подробно описать. Компиляторы высокоуровневых языков берут все это на себя, давая программисту возможность оперировать огромными частями программы с легкостью одной строчки.
А теперь "апогей" этой статейки - все эти недостатки могут быть бесследно стерты с истории ассемблера если в него просто добавить макросы. Разработка компилятора для ассемблера с хорошими макросами займет времени не больше, чем разработка какого-нибудь компилятора Visual C++, но вот результат будет гораздо лучше, т.к. язык, обладающий преимуществами и лишенный недостатков чистого ассемблера, - это величайший язык. Ведь если хорошо постараться с разработкой макросов, сделать их использование свободным, не стесняющим возможностей чистого ассемблера, то тогда вполне можно будет создать такой вот величайший язык. Было бы желание. Но почему-то у великих кампаний нет желания связываться с ассемблером, им проще списать его в число древних ископаемых, которые уже не способны сравниться с их могучими титанами С++, Object Pascal, Basic, Fortran, Lisp, Prolog, и т.д. и т.п. Собственно, ассемблер пытались списать со счетов с тех самых пор, когда в обиходе стали использоваться высокоуровневые языки (а это более двадцати лет назад), но безуспешно. FASM (Flat Assembler) - первая (известная мне) попытка реализовать такие макросы. Но этот ассемблер поддерживает (если поддерживает) всего-лишь один человек, соответственно несмотря на отличные, оригинальные и многофункциональные макросы, FASM все еще не может избавиться от своих недостатков, хотя и уменьшил их сравнительно с TASM, MASM или другими ассемблерами. К тому же у него нет хорошего IDE, т.к. Fresh - единственный более-менее удобный IDE - не может поравняться с современными интерфейсными монстрами.
Выводы из рассуждений: единственные две вещи, необходимые для того, чтобы на долгие и долгие годы возродить ассемблер и поднять его на несколько порядков выше высокоуровневых языков, это проработанный язык макросов и многофункциональный IDE. И эти две вещи не являются чем-то невозможным (ведь язык макросов едва ли будет сложнее, чем какой-нибудь язык С++, а уж IDE тем более легкая задача для таких матерых фирм, как Borland или мелкомягкие (впрочем, последние никогда не возьмутся за это, ведь у них же есть такой великолепный язык, как бейсик, компилятор для которого когда-то написал мальчик билли)). Но проблема в том, что все бояться ассемблера, как черт ладана.
-
-
10.11.2006 в 17:56И вообще если на то пошло, то можно писать в удобном микрсофтовском IDE на си со вставками на асме в критических местах. А вот асм макросами захламлять не стоит. MASM тому пример.
-
-
10.11.2006 в 21:33-
-
11.11.2006 в 16:11Ты понял про что я. Асм - не может и не должен быть основным языком разработки 8). Учитывая тенденции современного программирования 8). Так что имхо VC + WinAPI + ASM.
-
-
12.11.2006 в 17:51-
-
13.11.2006 в 09:53И нихуа тут не поделаешь. Ибо даже асм с мощными макросам будет проигрывать в легости разработки Аниси СИ.
А тут си шарп + удобное иде от микрософта.
У каждого языка своя ниша. У асма она очень маленькая. Но без нее не обойтись.
Кстати чем тебя си не устраивает? Поудобнее чем асм. 8). И я если честно не вижу причин для изобретения асма с мозными макросами. 8)). Си - переносимый асм + скорость разработки поболее чем на асме.
Вопрос прост. Чем тя си не устраивает?