Тогда отстается только написать заглушки в случае, если данная команда недоступна. Впрочем, ничего нового, так и пишут низкоуровневый системный код… Но терять в скорости исполнения из-за 1-20% процентов неподдерживающих устройств это, как мне кажется, глупо.
Ну не знаю… Операция с учетом флага переноса вещь очень древняя и любой современный компьютерный процессор поддерживает ее. А если вы пишите код для другого типа устройств, то вы знаете о их конфигурации и подбираете соответсвующие команды(в крайнем случае можно проверять что доступно, как это сделано tmmintrin.h)
Платформонезависимость ассемблера, как я уже написал выше, достигается процессом трансляции(построчный перевод нашего кода в код ассемблера) на этапе компиляции программы.
в Сasm-е написал не совсем правильный код, но общая идея понятна.
Синтаксис ассемблера можно выбрать из существующих или придумать свой. Но он не должен вставляться напрямую в ассемблер, а проходить процесс трансляции в компиляторе С.
Так далеко я там не смотрел…
Мне немного непонятно, что он имеет в виду под операциями… С функции? Если да, то это не совсем то что я хочу. Если мое предложение выразить в виде фрагмента кода, то получится следующее:
bool operator_plus(register dx, register si){
unsigned char flag;
Casm{
lodsl //перенести из указателя esi данные в eax
adcl ax, [dx] //сложение с учетом флага переноса
addl dx, 4 //инкремент второго указателя(первый - автоматически)
stosl //положить в edi результат
lahf //загрузить регистр флагов в ah
movb flag, ax //перебросить в переменную flag
}
return flag & 1; //если в результате суммирования возникло переполнение типа возвращаем его
}
Очень похожим способом реализовывались ассемблерные вставки в TurboС30...(1992 год выпуска)(в качестве компилятора asm тогда использовался TASM). У меня даже был опыт написания драйвера мыши под него, откуда и возник мой никнейм.
Я, конечно, плохо знаю, как там дела у microsoft, но для intel-овских процессоров есть даже специальная библиотека для работы с 128 разрядными числами, которая использует SIMD(tmmintrin.h, вспомнил эту статью)(может что есть и для amd).
Но допустим, что мы не хотим использовать ее и пишем собственную библиотеку на шаблонах wide_int. Тогда следующий вопрос к языку C: «В ассемблере уже много лет есть команда adc, которая складывает с учетом флага переноса, где она в С?»(Также еще можно поставить вопрос про SIMD и конвейерные инструкции). И количество таких вопросов огромно, когда мы начинаем копаться в возможностях С и ассемблера… И что самое важное, это полезные фичи ускоряющие процесс написания и скорость исполнения кода.
В общем, как мне кажется, стоит подумать в стандарте о реализации ключевого слова Casm(ассемблер из С), который бы предоставлял возможность писать платформонезависимые вставки(возможно программы) на ассемблере.(хотя обычно к моим идеям относятся негативно)
1)Насколько я понимаю, как будущий инженер, технология будет очень приближена к современным двоичным процессорам, поскольку требуется добавить всего одно состояние с противоположной разницей потенциалов(-1) на триггерных эл-тах(сейчас за 0 считается соответствующая разница потенциалов с некоторой погрешностью, а за 1 не накладывающаяся на 0-окрестность).
2)Как было сказано в посте, современная технология двоичных процессоров не может быть улучшена, из-за возникающих квантовых эффектов, в то время как троичные процессоры помогут еще ускорить наши машины… Их развитие будет скорее всего покрывать период в 10-20 лет, пока на сцену не зайдут квантовые процессоры или какое другое ноухау. На больший период их вряд ли хватит…
Разве онлайн конструкторы веб-сайтов нельзя считать автономным API?.. Человек говорит: «Хочу вот эту красивую кнопочку. А на нее наложить свойство onclick, которое будет открывать hide объект...» и т.д., и т.п.
Проблема документации в теории сейчас может быть решена с помощью код-анализатора на нейронных сетях, но окупаемость такого проекта, я думаю, будет за гранью разумного(в плохом смысле)…
А проблема изменяемости API может быть также решена с помощью своеобразной программы переводчика из одного API(старого) в другой API(новый), или из одного языка в другой… Но опять же без нейронных сетей, с некоторыми наперед прописанными шаблонами, переход на новый API не будет давать ускорения, а если что-то уже стало за это время deprecated?
Как я вижу будущее: надо создавать что-то наподобие умной нейронной сети, которая будет уметь конвертировать код между похожими языками(Pascal <-> C, Lua -> Python, ...), сама будет понимать иерархию класов и давать возможность сложной замены, содержать несколько шаблонов проектирования. Разрабатываться новые стандарты будут либо с помощью шаблонного программирования(+моментальное добавления нового API, т.к. мы считаем, что шаблоны не содержат в себе багов(были протестированны). Первичную документацию тоже будет легко добавлять, т.к. мы знаем способы «сложения» шаблон, и что каждый из них делает...), либо добавлением новых фич со сложным процессом внедрения(потребуется протестировать, найти места в старом API, которые можно улучшить с помощью этих фич, написать понятную документацию).
Обобщая сказаное в последнем параграфе на известном мне примере, у нас должен получиться своеобразный гибрид компилятора-транслятора,unity3d(простота),MSDN(Microsoft док. по С++ и др. языкам),STL(огромное кол-во шаблонов) и нейронных сетей анализа и оптимизации.(может что еще, да я не могу сформулировать)
В общем, учитывая тот факт, что я не видел хороших примеров программ, подходящих даже первому пункту, такое событие настанет ой как не скоро…
P.S. я еще молод и мало занимался веб разработкой и программированием под мобильные платформы, но могу сказать с точки зрения знаний по своей области(низкоуровневое программирование), что нам для начала нужно перейти на новое поколение языков программирования. Не в том смысле, что нужен более высокий уровень абстракции(хотя и он тоже), а отойти от канонов языка С. Этот язык действительно быстр и могуч, но написание на нем программ под современные платформы с большим кол-вом строк кода превращается в ад.(Для понимания в чем суть проблеммы возмите старый TurboC30(выполняющийся под эмулятором)(могу дать ссылку), и попробуйте написать на нем ассемблерные вставки(asm), графические объекты(graphics.h) и т.д.(там есть помощь по Ctrl+F1) Вы удивитесь насколько просто писать все это в тех далеких 90-х… А сейчас? средства графики — пожалуйста, directx и opengl, разбирайтесь, что нужно написать чтобы нарисовать простой круг; asm вставки — тоже легко, выбирай из 2 синтаксисов и не факт, что заработает; SSE(векторные) оптизации, ха, ну попробуй; а ведь еще, так за 40+ лет не додумались добавить в язык динамические объекты(функции, в частности, для С. Хотя бы возможность получения «сырого» адреса)) Этот язык безнадежно устарел, а как следствие устарели и все производные от него языки, как бы не хотел я этого признавать...(Python из-за этого сильно теряет в скорости) Поэтому сейчас я хочу как раз создать этот язык нового поколения… Пока есть только наброски, и неодобрение в первом чтении(версия 0.01), но надеюсь к версии 1.0 все изменится…
Платформонезависимость ассемблера, как я уже написал выше, достигается процессом трансляции(построчный перевод нашего кода в код ассемблера) на этапе компиляции программы.
Синтаксис ассемблера можно выбрать из существующих или придумать свой. Но он не должен вставляться напрямую в ассемблер, а проходить процесс трансляции в компиляторе С.
Мне немного непонятно, что он имеет в виду под операциями… С функции? Если да, то это не совсем то что я хочу. Если мое предложение выразить в виде фрагмента кода, то получится следующее:
Очень похожим способом реализовывались ассемблерные вставки в TurboС30...(1992 год выпуска)(в качестве компилятора asm тогда использовался TASM). У меня даже был опыт написания драйвера мыши под него, откуда и возник мой никнейм.
Но допустим, что мы не хотим использовать ее и пишем собственную библиотеку на шаблонах wide_int. Тогда следующий вопрос к языку C: «В ассемблере уже много лет есть команда adc, которая складывает с учетом флага переноса, где она в С?»(Также еще можно поставить вопрос про SIMD и конвейерные инструкции). И количество таких вопросов огромно, когда мы начинаем копаться в возможностях С и ассемблера… И что самое важное, это полезные фичи ускоряющие процесс написания и скорость исполнения кода.
В общем, как мне кажется, стоит подумать в стандарте о реализации ключевого слова Casm(ассемблер из С), который бы предоставлял возможность писать платформонезависимые вставки(возможно программы) на ассемблере.(хотя обычно к моим идеям относятся негативно)
2)Как было сказано в посте, современная технология двоичных процессоров не может быть улучшена, из-за возникающих квантовых эффектов, в то время как троичные процессоры помогут еще ускорить наши машины… Их развитие будет скорее всего покрывать период в 10-20 лет, пока на сцену не зайдут квантовые процессоры или какое другое ноухау. На больший период их вряд ли хватит…
Проблема документации в теории сейчас может быть решена с помощью код-анализатора на нейронных сетях, но окупаемость такого проекта, я думаю, будет за гранью разумного(в плохом смысле)…
А проблема изменяемости API может быть также решена с помощью своеобразной программы переводчика из одного API(старого) в другой API(новый), или из одного языка в другой… Но опять же без нейронных сетей, с некоторыми наперед прописанными шаблонами, переход на новый API не будет давать ускорения, а если что-то уже стало за это время deprecated?
Как я вижу будущее: надо создавать что-то наподобие умной нейронной сети, которая будет уметь конвертировать код между похожими языками(Pascal <-> C, Lua -> Python, ...), сама будет понимать иерархию класов и давать возможность сложной замены, содержать несколько шаблонов проектирования. Разрабатываться новые стандарты будут либо с помощью шаблонного программирования(+моментальное добавления нового API, т.к. мы считаем, что шаблоны не содержат в себе багов(были протестированны). Первичную документацию тоже будет легко добавлять, т.к. мы знаем способы «сложения» шаблон, и что каждый из них делает...), либо добавлением новых фич со сложным процессом внедрения(потребуется протестировать, найти места в старом API, которые можно улучшить с помощью этих фич, написать понятную документацию).
Обобщая сказаное в последнем параграфе на известном мне примере, у нас должен получиться своеобразный гибрид компилятора-транслятора,unity3d(простота),MSDN(Microsoft док. по С++ и др. языкам),STL(огромное кол-во шаблонов) и нейронных сетей анализа и оптимизации.(может что еще, да я не могу сформулировать)
В общем, учитывая тот факт, что я не видел хороших примеров программ, подходящих даже первому пункту, такое событие настанет ой как не скоро…
P.S. я еще молод и мало занимался веб разработкой и программированием под мобильные платформы, но могу сказать с точки зрения знаний по своей области(низкоуровневое программирование), что нам для начала нужно перейти на новое поколение языков программирования. Не в том смысле, что нужен более высокий уровень абстракции(хотя и он тоже), а отойти от канонов языка С. Этот язык действительно быстр и могуч, но написание на нем программ под современные платформы с большим кол-вом строк кода превращается в ад.(Для понимания в чем суть проблеммы возмите старый TurboC30(выполняющийся под эмулятором)(могу дать ссылку), и попробуйте написать на нем ассемблерные вставки(asm), графические объекты(graphics.h) и т.д.(там есть помощь по Ctrl+F1) Вы удивитесь насколько просто писать все это в тех далеких 90-х… А сейчас? средства графики — пожалуйста, directx и opengl, разбирайтесь, что нужно написать чтобы нарисовать простой круг; asm вставки — тоже легко, выбирай из 2 синтаксисов и не факт, что заработает; SSE(векторные) оптизации, ха, ну попробуй; а ведь еще, так за 40+ лет не додумались добавить в язык динамические объекты(функции, в частности, для С. Хотя бы возможность получения «сырого» адреса)) Этот язык безнадежно устарел, а как следствие устарели и все производные от него языки, как бы не хотел я этого признавать...(Python из-за этого сильно теряет в скорости) Поэтому сейчас я хочу как раз создать этот язык нового поколения… Пока есть только наброски, и неодобрение в первом чтении(версия 0.01), но надеюсь к версии 1.0 все изменится…