Есть идея, хотелось бы обсудить...
Недавно рисуя очередную программу под Мастдай 98, задумаля над проблемой оптимального кода. Ведь ни один высокоуровневый компилятор (комплятор языка высокого уровня) не может создать действительно оптимальный код... Единственная группа компиляторо которая спосбна на это - это компиляторы асм (ассеблера). И вот что я подумал, ведь есть же C++ Builder, VC, Delphi, VB, Java Builder и другие средства, так почему бы не появится некому ASM Builder? Я себе представляю это так: одно окно содержит текст программы на языке высокого уровня, но это не совсем язык, а скорее мета язык, даже алгоритм, к примеру:
целое_1_байт Главное_Начало ()
целое_2_байта: x = 2, y = 1;
строка_12_байт: приветмир = "Привет, Мир!";
устройство: _экран = ...;
// Параметры вывода на экран
Вывод (экран, x, y, приветмир);
Конец.
А рядом, в соседнем окне формируется код асм, соответствующий алгоритму, причем генерация идет примерно так:
; Главное_Начало
.
.
.
; целое_2_байта: x = 2, y = 1;
.
.
.
; строка_12_байт: приветмир = "Привет, Мир!";
.
.
.
; устройство: _экран = ...;
.
.
.
; Вывод (экран, x, y, приветмир);
.
.
.
; Конец.
.
.
.
И пользователь может изменить любой блок на асме, или написать свой, причем при изменении нужно переименовать блок, чтобы не болы путаницы:
целое_1_байт Главное_Начало ()
целое_2_байта: x = 2, y = 1;
строка_12_байт: приветмир = "Привет, Мир!";
Мой_Вывод (x, y, приветмир);
Конец.
Какие есть соображения братья по разуму?
Доброго вревени суток!
Недавно рисуя очередную программу под Мастдай 98, задумаля над проблемой оптимального кода. Ведь ни один высокоуровневый компилятор (комплятор языка высокого уровня) не может создать действительно оптимальный код... Единственная группа компиляторо которая спосбна на это - это компиляторы асм (ассеблера).
Маленькое замечание....
АСМ компиляторы на это не способны....
Это делает человек...
И вот что я подумал, ведь есть же C++ Builder, VC, Delphi, VB, Java Builder и другие средства, так почему бы не появится некому ASM Builder?
:)))
Я себе представляю это так: одно окно содержит текст программы на языке высокого уровня, но это не совсем язык, а скорее мета язык, даже алгоритм, к примеру:
Хочу тебя обрадовать идея метаязыка стара как мир... :)))
целое_1_байт Главное_Начало ()
целое_2_байта: x = 2, y = 1;
строка_12_байт: приветмир = "Привет, Мир!";
устройство: _экран = ...;
// Параметры вывода на экран
Вывод (экран, x, y, приветмир);
Конец.
А рядом, в соседнем окне формируется код асм, соответствующий алгоритму, причем генерация идет примерно так:
И пользователь может изменить любой блок на асме, или написать свой, причем при изменении нужно переименовать блок, чтобы не болы путаницы:
целое_1_байт Главное_Начало ()
целое_2_байта: x = 2, y = 1;
строка_12_байт: приветмир = "Привет, Мир!";
Мой_Вывод (x, y, приветмир);
Конец.
Какие есть соображения братья по разуму?
с
Рад видеть ещё одного созревшего человека, осознавшего что нужно искать выход в обънединении с асмом, а не в NET компонентах....
Доброго вревени суток!
Недавно рисуя очередную программу под Мастдай 98, задумаля над проблемой оптимального кода. Ведь ни один высокоуровневый компилятор (комплятор языка высокого уровня) не может создать действительно оптимальный код... Единственная группа компиляторо которая спосбна на это - это компиляторы асм (ассеблера). И вот что я подумал, ведь есть же C++ Builder, VC, Delphi, VB, Java Builder и другие средства, так почему бы не появится некому ASM Builder? Я себе представляю это так: одно окно содержит текст программы на языке высокого уровня, но это не совсем язык, а скорее мета язык, даже алгоритм, к примеру:
целое_1_байт Главное_Начало ()
целое_2_байта: x = 2, y = 1;
строка_12_байт: приветмир = "Привет, Мир!";
устройство: _экран = ...;
// Параметры вывода на экран
Вывод (экран, x, y, приветмир);
Конец.
А вот и не верным путем ты пошел.
Таким "мета языком", грубо говоря, является любой ЯВУ. ЯВУ призваны для того, чтобы облегчить написания программ за счет универсализации и улучшенных (более мощных) алгоритмических структур - отсюда и появляются излишки кода. Многие компиляторы просто переводят ЯВУ в ASM (вот как раз как ты хочешь) и потом уже они просто ассемблируются - генерируется машинный код.
Т.е. если ты пойдешь таким путем, то либо у тебя получется ассемблер слегка в упрощенной форме, но без всяких там крутых условных переходом, операторов циклов и т.д.; либо какой-то новый ЯВУ, но естественно он будет генерировать неоптимальный код и каждый раз подправлять его запаришься - оптимальные проги будут писаться тогда еще медленнее. Может я и не прав :)
Лично я считаю, что если и создавать ASM Builder, то главным его достоинством должно быть такое же простое создание форм. А обработчики событий уже писаться на ASM. То есть ASM Builder - это Дельфи, только ASM. Вот :).
А вот и не верным путем ты пошел.
Таким "мета языком", грубо говоря, является любой ЯВУ. ЯВУ призваны для того, чтобы облегчить написания программ за счет универсализации и улучшенных (более мощных) алгоритмических структур - отсюда и появляются излишки кода. Многие компиляторы просто переводят ЯВУ в ASM
Ну точнее таких уже не осталось....
Вот схема:
КОД ЯВУ -> ТОКЕН АНАЛИз -> МЕТАКОД -> ASM
(Оптимизацию я пропускаю...)
(вот как раз как ты хочешь) и потом уже они просто ассемблируются - генерируется машинный код.
Лично я считаю, что если и создавать ASM Builder, то главным его достоинством должно быть такое же простое создание форм. А обработчики событий уже писаться на ASM. То есть ASM Builder - это Дельфи, только ASM. Вот :).
Я убъю этого создателя :D
Чесное слово.....
- Д. Кнут
Глупо сейчас кодить на асме некритические участки кода. По времени выполнения разницы абсолютно никакой, а по времени разработки...
"Преждевременная оптимизация - корень всех зол."
- Д. Кнут
Глупо сейчас кодить на асме некритические участки кода. По времени выполнения разницы абсолютно никакой, а по времени разработки...
Зато какая красота исходника :D. Невольно вспоминается один мой корешок, который в АСМе полный ноль, да и вообще во всех остальных языках,а учится он на программиста. И он мне говорит: "Открываю я сделанную лабу, а там два столбца на несколько страниц :o". Конечно же писать на АСМе сейчас уже не модно. Хотя люди же все равно пишут даже то, что на нем писать не надо. Ну нравиться просто. Кстати я бы тоже писал бы только на нем если бы не сложные операции с вводом выводом + просто муторное программирование под Windows :). Все-таки: "С помощью языка ассемблера можно добиться наивысшей чистоты выходного кода и наибольшего быстродействия программ". Не помню кто это сказал :). Вот и приливает адреналин в кровь при программирование на АСМе.
Ну а насчет того, что скорость не ощущается, так ты по тактам посчитай и увидишь разницу :D. Ну и на самом деле - при ООП столько всяких callов, подcallов, даже при создании простенького окошечка на Builderе. А один call это же дополнительные такты процессора :o. Так что если мы в цикле обращаемся к какому-нибудь методу компонента - это порождает кучу всяких подcallов и прога работает гораздо медленнее :D. Хе-хе. Шучу я конечно, но все же....
А чегой-то вам мой ASM Builder не нравится :). Прикольно ведь - формы нарисовал, а потом на асме парься :).
Любой Builder - это ООП. ООП - смерть оптимизации по размеру/скорости.
Можно для этих целей использовать тот же Dельфи: попрощаться с VCL, begin - asm - pure WinAPI forever - end.
Да и вообще, смысл оптимизировать проги в неоптимизированной ОС...
Кстати, я сышал, что многие программисты на ASM-е признавали превосходство компиляторов перед ними в области низкоуровневой оптимизации кода. (ряд компилятов обращается к таблице тактов, таблицам совместимости пар команд, раскрывают циклы с учетом кэша, с учетом частоты обращения к переменным распределяют регистры, ...).
Важно понимать, что может оптимизатор, а чего нет, чтобы подсказать ему там, где он не догадается (например выделить временную переменную для временного хранения возвращаемого значения функции, вместо того, чтобы вызывать функцию два раза, ...).
Кроме того будет обидно вылизать и оптимизировать кусок кода на ASM-е, а затем увидеть более эффективную реализацию на VB за счет применения другого алгоритма.
Такое,в принципе, уже есть - частично. То есть виндовая оболочка для асмов и линков, с подсветкой синтаксиса и т.п. Но в целом не такая уж удобная штука.
И скоро готовиться.... :))) ещё одна... :))
Любой Builder - это ООП. ООП - смерть оптимизации по размеру/скорости.
Давайте не путать божий дар с яичницей...
ООП совершенно не причём к оптимизации -- ООП это всего лишь абстракция для удобного написания кода..., а не низкоуровневая методика кодинга....
Можно для этих целей использовать тот же Dельфи: попрощаться с VCL, begin - asm - pure WinAPI forever - end.
Да и вообще, смысл оптимизировать проги в неоптимизированной ОС...
А к стати, кому интересно об оптимизации кода для Win32 я писал в
Записки Дзенствующего
Кстати, я сышал, что многие программисты на ASM-е признавали превосходство компиляторов перед ними в области низкоуровневой оптимизации кода. (ряд компилятов обращается к таблице тактов, таблицам совместимости пар команд, раскрывают циклы с учетом кэша, с учетом частоты обращения к переменным распределяют регистры, ...).
Это всё так..., и кстати, вот здесь можно было бы помочь асму... .
Вот такая помощь была бы полезна в виде Интеллектуального модуля предварительной оптимизации
Важно понимать, что может оптимизатор, а чего нет, чтобы подсказать ему там, где он не догадается (например выделить временную переменную для временного хранения возвращаемого значения функции, вместо того, чтобы вызывать функцию два раза, ...).
Такая система слишком сложна, поэтому от её разработки отказались в своё время
Кроме того будет обидно вылизать и оптимизировать кусок кода на ASM-е, а затем увидеть более эффективную реализацию на VB за счет применения другого алгоритма.
Ну уж... кто ж вам дохтор :D