Здравствуйте, Pavel Dvorkin, Вы писали:
PD> H>По сути, VM и есть процессор. Были и кремниевые java-процессоры, это ничего не меняет.
PD> Ну тогда и, скажем, winrar есть процессор — для преобразования сжатого файла в несжатый. И т.д. и т.п.
По идее, так и есть (хотя, никому в голову не придет называть архиватор процессором). И что? Это не отменяет того факта, что байт-код является исполняемым по отношению к VM. Кстати, следуя твоей логике, x86-код тоже не является исполняемым т.к. напрямую эти инструкции современные процессоры не выполняют. Цитата для примера (источник):
В целом, микроархитектура Bobcat предполагает одновременное исполнение до двух x86 инструкций (в том числе и 64-битных). Конечно, процессор оперирует внутренними микрокомандами, но статистически до 89 % x86 инструкций преобразуется декодером Brazos в одну симметричную микрокоманду. Лишь 10 % инструкций декодируется в пару микрокоманд, а как несколько связанных микроопераций представляется не более 1 % входящих x86 команд.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Хм, мне кажется до сих пор речь шла об исполнении, а теперь вдруг о линковке... Перенести линкер от VS в Линукс никакой проблемы не составит, и MS могла бы это сделать быстро, если бы захотела — конечно, при условии, что генерировал бы он по-прежнему EXE/DLL, а не линуксовские исполняемые файлы. Только это никому не нужно.
В том то и дело, что бинарная совместимость в дотнете распространяется как на исполнение, так и на линковку. А для С++ нет ни того, ни другого. Дело не в запуске линкера, а в совместном использовании бинарной библиотеки под платформу А и приложения под платформу Б.
PD>Мы на "Вы" перешли ?
Ой, мне так проще, чем помнить, кому тыкать, а кому нет.
PD>Верно, сидит. Но вот тут-то и разница. Для нативного кода загрузчик код не генерирует, а только загружает. Он может вносить в него изменения (скажем, настраивать по .reloc), но он не может генерировать машинные команды.
Вы слишком много внимания уделяете несущественным деталям. Генерирует ли он команды jmp или только настраивает их параметры — не очень важно. Важно, что загрузчики для windows executable и для linux executable настолько разные, что они несовместимы между собой.
PD>Для ненативного генерирует. Если принять твою концепцию бинарности, то слишком далеко можно пойти. Например, архивируем программу на Бейсике и пишем интерпретатор, который деархивирует, интерпретирует и исполняет. Архивированный .bas — безусловно бинарный файл. Деархиватор-интерпретатор можно под любую платформу написать. Что же теперь, будешь утверждать, что и в этом случае имеет место бинарная совместимость ?
Конечно буду. Потому что ровно она и будет иметь место. Если я могу взять бинарную программу, и запустить её в целевом окружении, то чего ещё надо для щастя?
PD>С Явой то же самое. Байт-код бинарный. Байт-код годится для любой платформы (будем так считать, даже если это не на 100% верно). Но из этого не следует, что имеет место бинарная совместимость исполняемого кода, так как байт-код не является исполняемым кодом. Да и вообще он формально не код, а данные для java VM. Как и управляемый код в дотнетовской DLL не код , а данные для JIT.
Вы слишком много внимания уделяете несущественным деталям. Код от данных отличается только контекстом использования. Скажем, в Смолтоке или в Лиспе вы вообще не можете отличить одно от другого. Это не делает код на этих языках менее кодом.
В строгом определении, "исполняемый код" вышел из моды вместе с форматом .com файлов, т.к. всё остальное "исполнять" напрямую нельзя — нужно заниматься подготовкой к исполнению. А объём этой подготовки — дело вторичное.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[22]: на каком языке вам приятнее всего программировать ?
Здравствуйте, Mamut, Вы писали:
M> H>По сути, VM и есть процессор. Были и кремниевые java-процессоры, это ничего не меняет.
M> Не спорь. У Павла есть жестко прописанный набор стандартов уровня 1995-го года. Если что-то не вмещается в прокрустово ложе этих стандартов, это что-то объявляется неверным, ложным и т.п.
Здравствуйте, hattab, Вы писали:
PD>> Ну тогда и, скажем, winrar есть процессор — для преобразования сжатого файла в несжатый. И т.д. и т.п.
H>По идее, так и есть (хотя, никому в голову не придет называть архиватор процессором). И что?
Ничего, кроме того, что тогда почти любая программа есть процессор и исчезает тема рассуждений.
>Это не отменяет того факта, что байт-код является исполняемым по отношению к VM. Кстати, следуя твоей логике, x86-код тоже не является исполняемым т.к. напрямую эти инструкции современные процессоры не выполняют. Цитата для примера (источник):
H>
В целом, микроархитектура Bobcat предполагает одновременное исполнение до двух x86 инструкций (в том числе и 64-битных). Конечно, процессор оперирует внутренними микрокомандами, но статистически до 89 % x86 инструкций преобразуется декодером Brazos в одну симметричную микрокоманду. Лишь 10 % инструкций декодируется в пару микрокоманд, а как несколько связанных микроопераций представляется не более 1 % входящих x86 команд.
Если бы программист(компилятор) мог писать программы либо на ассемблере x86/64, либо на языке этих микрокоманд, я бы с тобой согласился. Но такой возможности нет. Это ниже уровня программирования, а поэтому должно быть отнесено к особенностям аппаратной реализации — точно так же, как и электрические сигналы и т.п.
With best regards
Pavel Dvorkin
Re[19]: на каком языке вам приятнее всего программировать ?
Здравствуйте, Sinclair, Вы писали:
S>В том то и дело, что бинарная совместимость в дотнете распространяется как на исполнение, так и на линковку. А для С++ нет ни того, ни другого. Дело не в запуске линкера, а в совместном использовании бинарной библиотеки под платформу А и приложения под платформу Б.
Ты с Mono работал ?
Нет никаких бинарных библиотек и приложений под платформу A (Windows) и Б (Linux). Компилятор Mono создает обычный EXE или DLL, с той же структурой, что и Visual Studio. Я писал программу в VS, делал EXE файл, а заказчик потом исполнял его в линуксе. Другое дело, что он использует системные библиотеки, которые в Windows и Linux отличаются, но опять же не по структуре, а по своим действиям на неуправляемом уровне.
PD>>Верно, сидит. Но вот тут-то и разница. Для нативного кода загрузчик код не генерирует, а только загружает. Он может вносить в него изменения (скажем, настраивать по .reloc), но он не может генерировать машинные команды. S>Вы слишком много внимания уделяете несущественным деталям. Генерирует ли он команды jmp или только настраивает их параметры — не очень важно. Важно, что загрузчики для windows executable и для linux executable настолько разные, что они несовместимы между собой.
Это не есть несущественные детали. Он, кстати, и команды jmp не генерирует. Он просто маппирует EXE/DLL в АП по механизму mmf, иногда изменяя некоторые константы (из .reloc). Никакой код он не генерирует — у него попросту нет никаких данных, чтобы это делать. В отличие от JIT.
PD>>Для ненативного генерирует. Если принять твою концепцию бинарности, то слишком далеко можно пойти. Например, архивируем программу на Бейсике и пишем интерпретатор, который деархивирует, интерпретирует и исполняет. Архивированный .bas — безусловно бинарный файл. Деархиватор-интерпретатор можно под любую платформу написать. Что же теперь, будешь утверждать, что и в этом случае имеет место бинарная совместимость ? S>Конечно буду. Потому что ровно она и будет иметь место. Если я могу взять бинарную программу, и запустить её в целевом окружении, то чего ещё надо для щастя?
Тогда и для неархивированного Бейсика можно тоже говорить о бинарной совместимости. Кто мне запретит текстовый файл считать бинарным ? Исключим из этой моей схемы архивацию/деархивацию, и будет то же самое, так ?
Но тогда и для C++ имеет место бинарная совместимость — я же могу взять бинарную программу (компилятор + линкер) и запустить эту С++ программу в ином окружении, если, конечно, она не использует ничего сверх стандарта С++. Полное "щастя" . Да, мне придется делать это при каждом запуске, так и JIT при каждом запуске свою работу делает, и интерпретатор Бейсика тоже.
PD>>С Явой то же самое. Байт-код бинарный. Байт-код годится для любой платформы (будем так считать, даже если это не на 100% верно). Но из этого не следует, что имеет место бинарная совместимость исполняемого кода, так как байт-код не является исполняемым кодом. Да и вообще он формально не код, а данные для java VM. Как и управляемый код в дотнетовской DLL не код , а данные для JIT. S>Вы слишком много внимания уделяете несущественным деталям. Код от данных отличается только контекстом использования. Скажем, в Смолтоке или в Лиспе вы вообще не можете отличить одно от другого. Это не делает код на этих языках менее кодом.
В Смолтоке , Лиспе или Бейсике можете называть кодом что хотите, а для процессора код — это то, на что можно передать управление из ОС с помощью машинных команд типа jmp, call и т.д, после чего он будет исполняться процессором.
S>В строгом определении, "исполняемый код" вышел из моды вместе с форматом .com файлов, т.к. всё остальное "исполнять" напрямую нельзя — нужно заниматься подготовкой к исполнению. А объём этой подготовки — дело вторичное.
Если это дело вторичное — тогда мы имеем эту самую совместимость для любого языка по причинам, изложенным мной чуть выше.
With best regards
Pavel Dvorkin
Re[24]: на каком языке вам приятнее всего программировать ?
Здравствуйте, Pavel Dvorkin, Вы писали:
PD> H>По идее, так и есть (хотя, никому в голову не придет называть архиватор процессором). И что?
PD> Ничего, кроме того, что тогда почти любая программа есть процессор и исчезает тема рассуждений.
Вот именно. Спрашивается, нафига ты сюда архиватор притянул Говоря о CPU и VM мы говорим, вообще-то, об одном и том же. Только первый воплощен в кремние, а вторая существует в виде программной реализации.
PD> Если бы программист(компилятор) мог писать программы либо на ассемблере x86/64, либо на языке этих микрокоманд, я бы с тобой согласился. Но такой возможности нет. Это ниже уровня программирования, а поэтому должно быть отнесено к особенностям аппаратной реализации — точно так же, как и электрические сигналы и т.п.
Программист/компилятор под VM так же ограничен ассемблером этой VM, и не может использовать команды CPU на котором работает VM. Для VM ассемблером является её байт-код, и она также может выполнять его разными путями. Соответствие просто зеркальное.
Здравствуйте, hattab, Вы писали:
H>Вот именно. Спрашивается, нафига ты сюда архиватор притянул
Для Синклера , см. ветвь дискуссии с ним. Я же ему отвечал.
>Говоря о CPU и VM мы говорим, вообще-то, об одном и том же. Только первый воплощен в кремние, а вторая существует в виде программной реализации.
Совершенно верно. Software and hardware. Вот только первое под программистским контролем, а второе нет.
PD>> Если бы программист(компилятор) мог писать программы либо на ассемблере x86/64, либо на языке этих микрокоманд, я бы с тобой согласился. Но такой возможности нет. Это ниже уровня программирования, а поэтому должно быть отнесено к особенностям аппаратной реализации — точно так же, как и электрические сигналы и т.п.
H>Программист/компилятор под VM так же ограничен ассемблером этой VM, и не может использовать команды CPU на котором работает VM. Для VM ассемблером является её байт-код, и она также может выполнять его разными путями. Соответствие просто зеркальное.
Да все верно, кроме того, что выделено выше. И это существенно. Потому что иначе я могу сказать, что и вообще все процессоры всех сортов совместимы между собой, и это будет верно на уровне чистой электродинамики.
With best regards
Pavel Dvorkin
Re[22]: на каком языке вам приятнее всего программировать ?
Неужто внезапно ? А я так полагал, что отвечаю Синклеру
S>Отож. Если нет платформенно-зависимого кода, то можно запросто взять программу, написанную под моно, запустить под гентой, и она зареференсит сборку, скомпилированную дотнетом под виндой, и даже создаст экземпляры типов из этой сборки, и сможет вызывать их методы. Вот это — бинарная совместимость.
S>>Отож. Если нет платформенно-зависимого кода, то можно запросто взять программу, написанную под моно, запустить под гентой, и она зареференсит сборку, скомпилированную дотнетом под виндой, и даже создаст экземпляры типов из этой сборки, и сможет вызывать их методы. Вот это — бинарная совместимость.
PD>http://rsdn.ru/forum/flame.comp/5040193.1
Здравствуйте, Mamut, Вы писали:
M> Я где-то что-то неправильно сказал?
Вот здесь
M>Павел, внезапно, о совместимости исполняемого кода.
Одно из двух — либо не заметил, что на эту тему перешел отнюдь не я (да еще внезапно), а Синклер, либо специально ... как бы это повежливее выразить... исказил истину
Если первое — надо бы просто извиниться, и инцидент исчерпан.
Но скорее второе, судя по сообщению, на которое я отвечаю. Да и по стилю ответов тоже.
>То, что оно для тебя некрасиво, это, извини, не моя проблема.
Для тебя должно быть некрасиво — попасть в такую ситуацию.
With best regards
Pavel Dvorkin
Re[6]: на каком языке вам приятнее всего программировать ?
Здравствуйте, Pavel Dvorkin, Вы писали:
PD> H>Вот именно. Спрашивается, нафига ты сюда архиватор притянул
PD> Для Синклера , см. ветвь дискуссии с ним. Я же ему отвечал.
.
PD> >Говоря о CPU и VM мы говорим, вообще-то, об одном и том же. Только первый воплощен в кремние, а вторая существует в виде программной реализации.
PD> Совершенно верно. Software and hardware. Вот только первое под программистским контролем, а второе нет.
Неверно. За рамки VM, ни компилятор, ни программист выйти не могут (то есть ни о каком контроле не может идти речи). И именно благодаря этому, исполняемый код является переносимым вне зависимости от платформы на которой работает VM.
PD> PD>> Если бы программист(компилятор) мог писать программы либо на ассемблере x86/64, либо на языке этих микрокоманд, я бы с тобой согласился. Но такой возможности нет. Это ниже уровня программирования, а поэтому должно быть отнесено к особенностям аппаратной реализации — точно так же, как и электрические сигналы и т.п.
PD> H>Программист/компилятор под VM так же ограничен ассемблером этой VM, и не может использовать команды CPU на котором работает VM. Для VM ассемблером является её байт-код, и она также может выполнять его разными путями. Соответствие просто зеркальное.
PD> Да все верно, кроме того, что выделено выше. И это существенно. Потому что иначе я могу сказать, что и вообще все процессоры всех сортов совместимы между собой, и это будет верно на уровне чистой электродинамики.
У процессоров и VM есть система команд, и говорим мы о ней, и ни о чем другом.
M>>Павел, внезапно, о совместимости исполняемого кода. PD>Одно из двух — либо не заметил, что на эту тему перешел отнюдь не я (да еще внезапно), а Синклер, либо специально ... как бы это повежливее выразить... исказил истину
Да-да. Все, что не умещается в стандарты 95-го года, это искажение истины, мы в курсе. Синклер объяснил, что он имел в виду. И не только Синклер.
>>То, что оно для тебя некрасиво, это, извини, не моя проблема. PD>Для тебя должно быть некрасиво — попасть в такую ситуацию.
Ситуации нет. Я описываю то, что вижу и видел до этого Тебе это не нравится? Извини, это не моя проблема.
Здравствуйте, Sheridan, Вы писали:
S>Да. Хотя бы потому как ее продуктом пользуются миллионы (миллиарды?) людей. И не знаю как тебе, а вот лично мне жутко интересно S>Вообще, качество кода виндов под сомнением.
Продукты MS в силу закрытости исходников неприменимы например для серьёзных стартапов. Никогда Google не стал Google если бы юзали винду, с закрытыми исходниками нельзя ни TCP стек под свои задачи заточить, ни кучи других системных вещей нельзя переделать. Даже вконтакте и тот в ядре Linux под себя TCP стек затачивал.
Если MS не хочет крякнуть им нужно открывать исходники винды и бесплатно её раздавать...
Re[13]: на каком языке вам приятнее всего программировать ?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>С MVC все немного интереснее (по крайней мере было, когда я с этим сталкивался) — лицензия позволяет запускать под Моно родные МСные сборки, так что сам Моно разработкой собственной вариации MVC не занимается.
С обычным ASP.NET тоже самое. Про WCF кто нибудь вкурсе?
Re[31]: на каком языке вам приятнее всего программировать ?
Здравствуйте, sysenter, Вы писали:
S>С обычным ASP.NET тоже самое.
Точно нет. Обычный ASP.NET поставляется только в составе фреймворка, а лицензия фреймворка не позволяет его сборки запускать в чужих рантаймах. MVC же, помимо фреймворка, лежит отдельно на кодплексе, и там лицензия несколько другая.
S> Про WCF кто нибудь вкурсе?
А что тебя про него интересует?
Re[32]: на каком языке вам приятнее всего программировать ?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Точно нет. Обычный ASP.NET поставляется только в составе фреймворка, а лицензия фреймворка не позволяет его сборки запускать в чужих рантаймах. MVC же, помимо фреймворка, лежит отдельно на кодплексе, и там лицензия несколько другая.
MS открыл исходники ASP.NET 4.0 и теперь mono содержит именно эти исходники.
НС>А что тебя про него интересует?
Уже на сайте mono посмотрел.
Re[33]: на каком языке вам приятнее всего программировать ?
А тебе уж в качестве повтора. Впрочем, я от своих слов не отказываюсь.
PD>> >Говоря о CPU и VM мы говорим, вообще-то, об одном и том же. Только первый воплощен в кремние, а вторая существует в виде программной реализации.
PD>> Совершенно верно. Software and hardware. Вот только первое под программистским контролем, а второе нет.
H>Неверно. За рамки VM, ни компилятор, ни программист выйти не могут (то есть ни о каком контроле не может идти речи). И именно благодаря этому, исполняемый код является переносимым вне зависимости от платформы на которой работает VM.
JNI есть выход за рамки VM или нет ?
А вот за рамки x86/x64 asm мне нействительно не выйти.
H>У процессоров и VM есть система команд, и говорим мы о ней, и ни о чем другом.
Спор, похоже, пора заканчивать. В сущнсти, у нас просто разные подходы. Если считать VM специализированным процессором, то ты прав. Если вспомнить, что она сама процесс ОС, то прав я. Так что вопрос, в сущности, об уровне, ниже которого выйти нельзя при определении этой самой бинарной совместимости. Я предлагаю уровень, самый верхний после аппаратуры, он же самый нижний программируемый. Ты берешь следующий программируемый уровень. Вот и все.
Говоря о CPU и VM мы говорим, вообще-то, об одном и том же. Только первый воплощен в кремние, а вторая существует в виде программной реализации.
