1 Января был анонсирован выход операционной системы Sharpos полностью написанной на C#. В отличие от сингулярити эта ОС действительно написанна полностью на C#, для достижения этого они создали свой компилятор в Native и библиотеку ASM в которой есть все x86 команды. Пример вызова ASM.Mov(.. , ..). Когда компилятор встречает такой вызов тогда он вставляет эту команду непосредственно в код как есть.

Проект безусловно интересен для всех .net разработчиков, и доступен ввиде исходников, бинарников и образов для популярных виртуальных ПК. На сайте есть скриншоты и видео. Сорцы компилятора тоже доступны.

-----
have a nice day

Тема поехала в оффтоп.

egorovshura пишет:
По поводу асма: мне приходилось работать с очень опытными программистами на C++, которые не только не знали асма, но и считали что его знание вредно.
Это значит всего лиш следующее:
1. либо они писали преимущественно офисный или бухгалтерский софт где вычислительная сложность заключается в одной формуле +/-/mul/div и основная задача это сделать красивый интерфейс чтоб юзеру нравилось
2. либо они просто ошибались - т.к. системные вещи писать гораздо проще зная ASM и понимая как это работает изнутри.
А вообще странная точка зрения.
Утверждать что знание ASM вредно может человек который его ЗНАЕТ, но при этом ему это навредило - т.е. чем-то мешает.
Ты же пишеш что они ASM не знают - как они тогда могут утверждать что его знание вредно если сами не пробовали?

cppasm
Человек который мне это сказал бухгалтерского софта и прочих глупостей никогда не писал. Также он ярый противник RAD разработки. На C++ писал корпоративные сервера, OLE DB провадеры и тому подобные вещи.
А позиция его следующая: не нужно понимать как это устроено внутри. Есть некий уровень абстракции на котором мы работаем и нужно оперировать понятиями этого уровня а не спускаться вниз. Чтобы было если бы в арифметике мы каждый раз считали бы таблицу умножения вместо того чтобы один раз выучить ее и в дальнейшем пользоваться не задумываясь о том "как это работает изнутри". Абстрагирование есть способ борьбы со сложностью. В таком ракурсе знание деталей действительно вредно.

Сколько людей из тех кто пишет на ассемблере задумывается как процессор выполняет команды? Ведь команды ассемблера - это не атомы. Они состоят из более мелких команд, почему бы тогда каждый раз не проверять, правильно ли работает данная команда ассемблера? Или того лучше с осциллографом замерять сигналы на ножках процессора и думать о том где открываются и закрываются транзисторы в процессоре?
Мне например не нужно это знать для того чтобы написать программу на ассемблере. Наинизший уровень до которого я доходил это, как производится выборка команд и данных, как работает кеш процессора, очередь команд и трубы. Но это только потому что была специфическая задача: максимально оптимизировать функцию под определенный процессор. Все остальное время я прекрасно обхожусь без этих знаний. и сейчас я уже даже не представляю как там что работает.

egorovshura пишет:
Чтобы было если бы в арифметике мы каждый раз считали бы таблицу умножения вместо того чтобы один раз выучить ее и в дальнейшем пользоваться не задумываясь о том "как это работает изнутри".
А я не говорю каждый раз считать таблицу умножения - я говорю надо знать как она считается.
Это разные вещи.
И если вдруг ты когда-нибудь забудеш её часть или запомниш неправильно всегда можно перепроверить.
egorovshura пишет:
Сколько людей из тех кто пишет на ассемблере задумывается как процессор выполняет команды?
Из тех кто не вчера стал писать на ASM - много. Гораздо больше чем среди тех кто пишет на HLL.
egorovshura пишет:
почему бы тогда каждый раз не проверять, правильно ли работает данная команда ассемблера? Или того лучше с осциллографом замерять сигналы на ножках процессора и думать о том где открываются и закрываются транзисторы в процессоре?
А смысл? Даже если ты обнаружиш ошибку - исправить её не в твоих силах.
А вот если ты обнаружиш ошибку в ПО (библиотеке и т.д.) на которое опирается твоё - её всегда можно исправить.
Знание ассемблера очень сильно помогает в понимании самой архитектуры и помогает более глубоко понять принципы тех же высокоуровневых языков.
Не возникают вопросы такого типа "А почему в Си нельзя одной строке присвоит другую (Str1=Str2)" или "А почему я пишу ResStr=Str1+Str2, а получаю не конкатенацию а вообще мусор".
А таких вопросов просто куча, достаточно пару форумов по программированию пролистать.

egorovshura пишет:
Такое делать никто не будет в реальной жизни
Да, для такого логичнее std::copy

egorovshura пишет:
Но я в шарпе не очень разбираюсь, так что возможно проще можно сделать
Надеюсь, что можно, посмотрим, что напишет гуру А то твой пример лишь показывает, что на любом Тьюринг-полном языке можно впринципе решать одинаковые задачи =)

egorovshura пишет:
Не поверю пока не увижу своими глазами. Или у нас разное понятие о сложности. Самый серьезный проект на C++ в котором я участвовал это более 500.000 строк кода
Извини, но на "слабо" сорцы показывать глупо =) Я их и сам не видел, и скока LOC не знаю (да и это абсолютно ничего не показывает, как известно, самые серъезные оптимизации - архитектурные, а ценность софта определяется решаемыми пробоемами). Речь о кластеризуемом вебсервере - клоне __combats_ru. Можно ли его где-то сейчас посмотреть в работе - хз, это не знает вроде и сам дев, у __freelands_ru оказался гнилой конец :\

egorovshura пишет:
который писался больше 10 лет.
Дык вот она и причина - это по-сути помойка, а не код. 10 лет назад даже С++ был другой... Ну и интересно, есть ли проекты на шарпе которые писались столько лет?

egorovshura пишет:
позиция его следующая: не нужно понимать как это устроено внутри. Есть некий уровень абстракции на котором мы работаем и нужно оперировать понятиями этого уровня а не спускаться вниз.
Чел о котором я писал выше собственно так и изучил С++ - разобрался, что из себя представляет эта абстракция (он кроме перла еще Z80 asm знал +). И я его тоже так изучил. А Страуструп - так его написал - запарили его и знакомых асм и ограниченность С. А твой чел элементарно не сможет локализовать баг из-за _ошибки_компилятора_