Платформонезависимость
Я, например, вообще скептически к ней отношусь. Ну, сделают, допустим, дум4 кроссплатформенным. В него можно будет без рефакторинга, без переписывания кода и даже без ребилда гамать как с креев, так и с сотового телефона. А заодно со стиральной машины, с маршрутизаторов, с маковского ноутбука и с силиконовского компа. Ну, и зачем?
Меня всё-таки больше интересует этот вопрос в контексте ЯП. Некоторые люди высказывали мнение, что сабж == наличие виртуальной машины. Я с такой точкой зрения не согласен. Например, такой разве язык, как Пролог, зависим от платформы? И тем не менее, никакой Виртуальной Машины Пролога в природе не существует. Насколько я знаю.
никакой Виртуальной Машины Пролога в природе не существует
Пролог вроде как интерпретируемый... А что ты вообще понимаешь под словами "виртуальная машина"?
> Например, такой разве язык, как Пролог, зависим от платформы? И тем не менее, никакой Виртуальной Машины Пролога в природе не существует.
встречный вопрос:
JavaScript платформонезависим?
у JavaScript-а виртуальная машина есть?
встречный вопрос:
JavaScript платформонезависим?
у JavaScript-а виртуальная машина есть?
Под виртуальной машиной я понимаю виртуальную машину и ничего более. Среду, которая исполняет промежуточный код, единый для всех платформ и осей.
Фишка в том, что я не считаю, что наличие промежуточного кода гарантирует кроссплатформенность и наоборот. Промежуточный код был придуман ещё Виртом для своего Паскаля, когда ни о какой Джаве ещё даже думать не могли.
Фишка в том, что я не считаю, что наличие промежуточного кода гарантирует кроссплатформенность и наоборот. Промежуточный код был придуман ещё Виртом для своего Паскаля, когда ни о какой Джаве ещё даже думать не могли.
Кстати, пролог вполне себе компилируемый язык. Так же как и лисп, и ещё много чего. И то, что когда-то давно он интерпретировался и не мог компилироваться - ни о чём не говорит.
Промежуточный код был придуман ещё Виртом для своего Паскаляreally?
А что, паскаль придуманный виртом - не кросплатформенный?
Да, кстати. Самый кроссплатформенный язык - это бейсик. Он был реализован на таком количестве программно-аппаратных комплексов, што пиздец!
Да, кстати. Самый кроссплатформенный язык - это бейсик. Он был реализован на таком количестве программно-аппаратных комплексов, што пиздец!
Только назывался, почему-то, не бейсик, а StarBASIC, QBasic, GWBasic... 
> Только назывался, почему-то, не бейсик, а StarBASIC, QBasic, GWBasic...
И везде был немного не таким, как другие бейсики. Мб тогда и ассемблер считать кроссплатформенным?
И везде был немного не таким, как другие бейсики. Мб тогда и ассемблер считать кроссплатформенным?
ФЖ, теперь моя очередь сказать - не говори того, чего не знаешь. Бейсики на разных машинах настолько различаются, что даже шарп и плюсы покажутся по сравнению с этим одним и тем же языком.
Паскаль, придуманный Виртом, разумеется, не кроссплатформенный. И дело не в размерах интов. Ты в курсе, как там устроена система ввода-вывода? В Виртовсокм Паскале, а не в Турбо?
А, скажем, фрипаскаль кроссплатформенный, насколько я знаю, хотя в нём никаких промежуточных кодов нету. Так что, ФЖ, рано ты начал ставить знак равенста между наличием виртуальной машины и кроссплатформенностью.
Паскаль, придуманный Виртом, разумеется, не кроссплатформенный. И дело не в размерах интов. Ты в курсе, как там устроена система ввода-вывода? В Виртовсокм Паскале, а не в Турбо?
А, скажем, фрипаскаль кроссплатформенный, насколько я знаю, хотя в нём никаких промежуточных кодов нету. Так что, ФЖ, рано ты начал ставить знак равенста между наличием виртуальной машины и кроссплатформенностью.
reallyПромежуточный код был придуман ещё Виртом для своего Паскаляreally?
Ну слушай, я же тебе привёл пример.
Очень большое количество машЫн (от микропроцессоров до суперкомпов) имеют LittleEndian архитектуру. Когда четырёхбайтовый инт 0x12345678 хранится в памяти именно так, а не как 0x78 56 34 12. Если у тебя язык "без виртуальной машины" и в нём есть указатели, то первая же попытка пройтись по массиву интов указателем на байт продемонстрирует некоторую архитектурную зависимость.
Да, кстати. Ты ж вроде представляешь себе, что происходит с кодом на шарпе во время компиляции и исполнения, да? Ну тогда скажи, что собой представляет "виртуальная машина" для шарпа. Полагаю, когда ты это сформулируешь (сам твоё сознание расширится.
Очень большое количество машЫн (от микропроцессоров до суперкомпов) имеют LittleEndian архитектуру. Когда четырёхбайтовый инт 0x12345678 хранится в памяти именно так, а не как 0x78 56 34 12. Если у тебя язык "без виртуальной машины" и в нём есть указатели, то первая же попытка пройтись по массиву интов указателем на байт продемонстрирует некоторую архитектурную зависимость.
Да, кстати. Ты ж вроде представляешь себе, что происходит с кодом на шарпе во время компиляции и исполнения, да? Ну тогда скажи, что собой представляет "виртуальная машина" для шарпа. Полагаю, когда ты это сформулируешь (сам твоё сознание расширится.
О! Заодно еще вопрос:
Есть ли "виртуальная машина" в языке С, и насколько она "виртуальная"?
Есть ли "виртуальная машина" в языке С, и насколько она "виртуальная"?
ФЖ, я же сказал, что такое ВМ в моём понимании. Компилятор шарпа генерит промежуточный код, а уже ВМ в лице джиттера делает из него что-то удобоваримое. Для сей, оф коз, никакой ВМ нет, потому что код генерится сразу исполнимый.
А что касается твоих примеров с указателями - могу привести другой пример. Если на всеми любимой платформонезависимой Джаве написать файл не в нотации винды, а в нотации юникс, то на виндовой машине вся платформонезависимость будет сосать. Так что хакнуть кроссплатформенность всегда можно. В таком случае, сабж вообще не существует.
А что касается твоих примеров с указателями - могу привести другой пример. Если на всеми любимой платформонезависимой Джаве написать файл не в нотации винды, а в нотации юникс, то на виндовой машине вся платформонезависимость будет сосать. Так что хакнуть кроссплатформенность всегда можно. В таком случае, сабж вообще не существует.
С тобой очень приятно спорить, Сатурн. Потому что ты постоянно выдаёшь ложные легкоопровергаемые утверждения.
Привет!
А сказал херню ты именно по той причине, что считаешь, что у С нет виртуальной машины. Фишка в том, что подсистемы ввода/вывода, выделения памяти, и еще хз какие представляют собой самую что ни на есть виртуальную машину. Мне щаз влом проверять, но если мне не изменяет память, fopen под виндами тоже прекрасно жрёт юниксовую нотацию. "Все хоть сколько-нибудь POSIX-совместимые системы сосут"(с) Pablito =)
Другое дело, что центральный процессор - он-то остаётся! Поэтому чтобы прогу можно было бы запустить на _любом_ процессоре, её придётся действительно интерпретировать, а промежуточный код нужен фактически с единственной целью - чтобы можно было быстро интерпретировать. Хотя если в языке, например, нету указателей, то для подавляющего большинства процессоров можно сгенерить непосредственно исполняемый код.
При этом когда ты программируешь на каком-нибудь языке, фактически ты программируешь на смеси "виртуальной машины" состоящей из а) непосредственно объектов языка (интов, булов, етс.) и стандартных библиотечных функций (которые ВЕЗДЕ работают одинаково, на то они и библиотечные функции и б) "реальной машины", состоящей из конкретного железа (с конкретным размером машинного слова, порядком байтов в слове, количеством регистров и моделью памяти) и внешних программ (операционки).
Если твой язык позволяет на данной конкретной задаче свести часть (б) к нулю, то у тебя получается абсолютно платформонезависимая программа. То есть если кто-нибудь построит компилятор и стандартные библиотеки для БК0010, и твоя прога влезет в память, то она будет на нём работать.
Далее, кроме стандартных библиотек есть ещё распространённые библиотеки - openGl, например. Если твоя программа использует их, то количество платформ на которых она может быть запущена снижается незначительно.
Так же может быть ситуация, когда язык специально спроектирован так, чтобы было невозможно "хакнуть" кроссплатформенность. Например, жаваскрипт. Не тот, который в WSH, а тот, который на хтмл-страничках.
При этом на языке С крайне тяжело писать кроссплатформенные проги - потому что размер инта скачет, например. А на языке С# достаточно легко писать кроссплатформенные проги. Или по крайней мере локализовать платформозависимые части в своих библиотеках, так что при переносе необходимо будет переписывать только их - благодаря тому, что некроссплатформенность в шарпе появляется только и исключительно при использовании функций ОС. Ну то есть конечно compact framework немного отличается от обычного, и директива unsafe позволяет очень интересные вещи делать, но это детали =)
Это, правда, не на жаве а на шарпе. Если на жаве так нельзя, то я ставлю тебе пиво, но на жаве так можно, конечно же =) В корне того диска, на котором будет лежать экзешник, не забудь создать папочку "abc", потому что File.Create только файл умеет создавать.
using System;
using System.IO;
namespace Zzzzz
{
public class Zzz
{
static void Main(string[] args)
{
FileStream fs = File.Create("/abc/abc.txt");
fs.Write(new byte[] {49, 50, 51}, 0, 3);
fs.Close;
}
}
}
Привет!
А сказал херню ты именно по той причине, что считаешь, что у С нет виртуальной машины. Фишка в том, что подсистемы ввода/вывода, выделения памяти, и еще хз какие представляют собой самую что ни на есть виртуальную машину. Мне щаз влом проверять, но если мне не изменяет память, fopen под виндами тоже прекрасно жрёт юниксовую нотацию. "Все хоть сколько-нибудь POSIX-совместимые системы сосут"(с) Pablito =)
Другое дело, что центральный процессор - он-то остаётся! Поэтому чтобы прогу можно было бы запустить на _любом_ процессоре, её придётся действительно интерпретировать, а промежуточный код нужен фактически с единственной целью - чтобы можно было быстро интерпретировать. Хотя если в языке, например, нету указателей, то для подавляющего большинства процессоров можно сгенерить непосредственно исполняемый код.
При этом когда ты программируешь на каком-нибудь языке, фактически ты программируешь на смеси "виртуальной машины" состоящей из а) непосредственно объектов языка (интов, булов, етс.) и стандартных библиотечных функций (которые ВЕЗДЕ работают одинаково, на то они и библиотечные функции и б) "реальной машины", состоящей из конкретного железа (с конкретным размером машинного слова, порядком байтов в слове, количеством регистров и моделью памяти) и внешних программ (операционки).
Если твой язык позволяет на данной конкретной задаче свести часть (б) к нулю, то у тебя получается абсолютно платформонезависимая программа. То есть если кто-нибудь построит компилятор и стандартные библиотеки для БК0010, и твоя прога влезет в память, то она будет на нём работать.
Далее, кроме стандартных библиотек есть ещё распространённые библиотеки - openGl, например. Если твоя программа использует их, то количество платформ на которых она может быть запущена снижается незначительно.
Так же может быть ситуация, когда язык специально спроектирован так, чтобы было невозможно "хакнуть" кроссплатформенность. Например, жаваскрипт. Не тот, который в WSH, а тот, который на хтмл-страничках.
При этом на языке С крайне тяжело писать кроссплатформенные проги - потому что размер инта скачет, например. А на языке С# достаточно легко писать кроссплатформенные проги. Или по крайней мере локализовать платформозависимые части в своих библиотеках, так что при переносе необходимо будет переписывать только их - благодаря тому, что некроссплатформенность в шарпе появляется только и исключительно при использовании функций ОС. Ну то есть конечно compact framework немного отличается от обычного, и директива unsafe позволяет очень интересные вещи делать, но это детали =)
Насчёт ложных утверждений - то же самое могу сказать про тебя, хотя, в отличие от тебя, мне неприятно слушать, когда, казалось бы, такой здравомыслящий человек говоришь ложные легкопроверяемые утверждения.
А насчёт ВМ я никакой херни не сказал, просто у тебя и остального мира разные понимания слов ВМ.
А насчёт ВМ я никакой херни не сказал, просто у тебя и остального мира разные понимания слов ВМ.
> просто у тебя и остального мира разные понимания слов ВМ.
При ссылке на "остальной мир", просьба подтверждать слова хоть какой-нибудь цитатой/определением.
При ссылке на "остальной мир", просьба подтверждать слова хоть какой-нибудь цитатой/определением.
Ты сказал прекрасное легкопроверяемое ложное утверждение:
Более того, слово "херня" относилась именно к этому утверждению (абсолютно справедливо и я указал на причину того, что подобная херня проникла в твою голову: ты не считаешь стандартные библиотеки языка С компонентами виртуальной машины.
Да, я был неправ в одном месте: "Все хоть сколько-нибудь POSIX-совместимые системы сосут" (c)Ignatich
Если на всеми любимой платформонезависимой Джаве написать файл не в нотации винды, а в нотации юникс, то на виндовой машине вся платформонезависимость будет сосать. Так что хакнуть кроссплатформенность всегда можно. В таком случае, сабж вообще не существует.Я продемонстрировал его ложность.
Более того, слово "херня" относилась именно к этому утверждению (абсолютно справедливо и я указал на причину того, что подобная херня проникла в твою голову: ты не считаешь стандартные библиотеки языка С компонентами виртуальной машины.
Да, я был неправ в одном месте: "Все хоть сколько-нибудь POSIX-совместимые системы сосут" (c)Ignatich
Я уже писал, что такое в моём понимании ВМ. Именно с таким определением я и встречаюсь в соответствующей литературе. Повторюсь: ВМ - это среда, интерпретирующая промежуточный код в машинные коды.
Именно этим Forth, Smalltalk, Java и C# отличаются от, скажем, С++ или Ады.
А в твоём понятии виртуальной машины я вообще не вижу смысла.
Именно этим Forth, Smalltalk, Java и C# отличаются от, скажем, С++ или Ады.
А в твоём понятии виртуальной машины я вообще не вижу смысла.
То есть если я, скажем, распространяю свою прогу на шарпе в сурцах, а её компилят уже на каждом компе, причем сразу в native (есть такая мега-утилитка то виртуальной машины нет?
Ты про Фреймворк-то?
Именно этим Forth, SmalltalkЭто не врите.
Есть native компиляторы.
> Повторюсь: ВМ - это среда, интерпретирующая промежуточный код в машинные коды.
Visual Basic 6 имеет виртуальную машину или нет?
Если имеет, то где там интерпретация?
Если не имеет, то почему "общее мнение", в том числе, думает по другому:
http://www.google.com/search?hl=en&lr=&q=Visual+Basic+6+virtual+machine
Visual Basic 6 имеет виртуальную машину или нет?
Если имеет, то где там интерпретация?
Если не имеет, то почему "общее мнение", в том числе, думает по другому:
http://www.google.com/search?hl=en&lr=&q=Visual+Basic+6+virtual+machine
А, скажем, фрипаскаль кроссплатформенный, насколько я знаю, хотя в нём никаких промежуточных кодов нету.В те времена, когда под FreeBSD число портов было меньше тысячи, один мой знакомый увлекался портированием всякого говна на FreeBSD. Вот взял он линуксовый фрипаскаль, и стал его обрабатывать напильником до тех пор, пока он не собрался на FreeBSD. Только вот, бинари он генерил по прежнему линуксовые...
Visual Basic 6 имеет виртуальную машину или нет?Именно так.
Насчёт этого врать не буду - во ФриПаскале я не рюх.
Что касается вопроса о наличии ВМ в сях, то у ФЖ замечательная позиция - в разных местах спора под одними и теми же словами понимать совершенно разные вещи и отказываться от своих слов.
Итак, начало:
ФЖ, ты сначала разберись с тем, что ты понимаешь под ВМ.
Что касается вопроса о наличии ВМ в сях, то у ФЖ замечательная позиция - в разных местах спора под одними и теми же словами понимать совершенно разные вещи и отказываться от своих слов.
Итак, начало:
С вообще нихуя не кроссплатформенныйМой приват:
Но ведь не одной виртуальной машиной живы платформонезависимые языки!Его ответ:
Ваще-то только и именно ей.Далее, в этом треде:
ты не считаешь стандартные библиотеки языка С компонентами виртуальной машины.Итак, подытожим. ФЖ говорит, что платформонезависимость == наличие виртуальной машины, у си она есть, однако си, как ни странно, отнюдь не кроссплатформенный язык.
ФЖ, ты сначала разберись с тем, что ты понимаешь под ВМ.
а ты читал в середине длинного поста Fj пункт б?
Если понимать под виртуальной машиной некий агрегат, который интерпретирует какую-то запись действий программы, то Visual Basic 6 не имеет виртуальной машины, msvbvm60.dll для программ, скомпилированных по умолчанию, представляет собой просто DLL с различными сервисными функциями (создать окошко, поискать по строке, выделить память для объекта). А название это перекочевало от тех древних времен, когда VB умел генерировать только P-код.
Не отвлекайтесь. Давайте все выскажутся, что они понимают под платформонезависимостью. А потом и ВМ можно обсудить.
Платформонезависимость - это такое слово, популярное у маркетологов и других людей, далёких от Software Engineering 
> А название это перекочевало от тех древних времен, когда VB умел генерировать только P-код.
раньше было плохо:
на стороне разработчика была генерация P-кода,
на стороне клиента P-код интерпретировался/компилировался в asm
и это называлось виртуальной машиной
далее изменили только следующее:
на стороне разработчика генерился P-код, который сразу же на стороне разработчика переводился в asm
И что? виртуальная машина сразу куда-то девалась?
ps
Хочешь сказать, что если я возьму .Net-сборку у себя ее обработаю ngen-ом, получу обычный asm, а потом ее отдам тебе, то ты хочешь сказать, что в этом случае никакой виртуальной машины нет?
так что ли?
раньше было плохо:
на стороне разработчика была генерация P-кода,
на стороне клиента P-код интерпретировался/компилировался в asm
и это называлось виртуальной машиной
далее изменили только следующее:
на стороне разработчика генерился P-код, который сразу же на стороне разработчика переводился в asm
И что? виртуальная машина сразу куда-то девалась?
ps
Хочешь сказать, что если я возьму .Net-сборку у себя ее обработаю ngen-ом, получу обычный asm, а потом ее отдам тебе, то ты хочешь сказать, что в этом случае никакой виртуальной машины нет?
так что ли?
Пишешь статью про платформу, которую никто не видел, но под которую код точно непереносим?
Интерпретировался/компилировался в асмЭту фразу стоит отредактировать во избежание длинного хвоста постов веселящихся товарищей.
и это называлось виртуальной машинойВиртуальной машиной называлась только вторая часть процесса, первая - средой разработки.
на стороне разработчика генерился P-код, который сразу же на стороне разработчика переводился в asmА вот это неправда, P-код в процессе компиляции теперь никак не участвует, VB-код транслируется средой в С++, а тот потом компилируется в ехешник отдельным компилятором: c2.exe.
Хочешь сказать, что если я возьму .Net-сборку у себя ее обработаю ngen-ом, получу обычный asm, а потом ее отдам тебе, то ты хочешь сказать, что в этом случае никакой виртуальной машины нет?Не уверен насчет ngen, но раз с моей стороны ассемблерный листинг или машинный код standalone, то с моей стороны ВМ нет. А что с твоей, не представляет интереса.
> Не уверен насчет ngen, но раз с моей стороны ассемблерный листинг или машинный код standalone, то с моей стороны ВМ нет.
Если следовать твоей логике, то в .Net-е, вообще, нет виртуальной машины, т.к. в .Net-е все выполняется native-код.
Native-код генерится при первом запуске, соответственно в памяти работает уже опять же native-код.
Я правильно тебя понял?
Если следовать твоей логике, то в .Net-е, вообще, нет виртуальной машины, т.к. в .Net-е все выполняется native-код.
Native-код генерится при первом запуске, соответственно в памяти работает уже опять же native-код.
Я правильно тебя понял?
Как бы мне не хотелось называть FW виртуальной машиной, вынужден признаться, что скорее это компилятор.
> Как бы мне не хотелось называть FW виртуальной машиной, вынужден признаться, что скорее это компилятор.
Java + Jit - это тоже компилятор?
Java + Jit - это тоже компилятор?
У Java есть JIT? Спасибо, не знал. Не думаю, что до бм подробного исследования смогу сделать вывод на этот счет...
Сильнее: что насчёт STC (Subroutine Threaded Code)?
---
"Расширь своё сознание!"
---
"Расширь своё сознание!"
Оставить комментарий
Flack_bfsp
Уважаемые форумчане! Хотелось бы услышать от различных людей мнения о сущности сабжа. Что вы под ним подразумеваете, что является для вас необходимым критерием сабжа, какие неотъемлемые части?