Как вы думаете, возможна ли полноценная кросплатформеность(в частности между 32 и 64 битными платформами), на уровне исходного текста(с перекомпиляцией но без измения исходного текста), без виртуальной машины(native)?
Спасибо.
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Здравствуйте, AlexCab, Вы писали:
AC>Как вы думаете, возможна ли полноценная кросплатформеность(в частности между 32 и 64 битными платформами), на уровне исходного текста(с перекомпиляцией но без измения исходного текста), без виртуальной машины(native)? AC>Спасибо.
Здравствуйте, hardcase, Вы писали:
H>А как ты думаешь, зачем size_t в C++ нужен?
То есть ты считаеш невозможна?
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Здравствуйте, AlexCab, Вы писали:
AC>Как вы думаете, возможна ли полноценная кросплатформеность(в частности между 32 и 64 битными платформами), на уровне исходного текста(с перекомпиляцией но без измения исходного текста), без виртуальной машины(native)? AC>Спасибо.
Ну она и сейчас возможна. например на C++ вполне можно написать программу, которая одинаково копмпилируется и работает на x86\x64, win\nix.
Другое дело что всегда так делать не получится, это требует дополнительных затрат. Самое главное тут что все различия убираются в библиотеки
Здравствуйте, hardcase, Вы писали:
H>Здравствуйте, AlexCab, Вы писали:
AC>>Как вы думаете, возможна ли полноценная кросплатформеность(в частности между 32 и 64 битными платформами), на уровне исходного текста(с перекомпиляцией но без измения исходного текста), без виртуальной машины(native)? AC>>Спасибо.
H>А как ты думаешь, зачем size_t в C++ нужен?
а что без него кроссплатформенность не обеспечить что ли? ну пусть у нас на 32 битах и size_t и int — 32 бита. пусть на 64 битах size_t 64 бита, а int — 32. при компиляции под 64 бита программа все еще работает с 4 гб памяти макс, а если и забыть unsigned перед int, то индексы дальше 2 Гб не стреляют. использование size_t автоматически бы увеличило предельно допустимый размер блоков с которыми мы можем работать, но если size_t не используется -- в худшем случае мы просто не увидим разницы между 64 и 32. большинство программ и так ее не видят и предельно допустимые размеры обрабатываемых файлов у текстовых редакторов автоматически не увеличиваются при компиляции под 64.
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Здравствуйте, AlexCab, Вы писали:
AC>Как вы думаете, возможна ли полноценная кросплатформеность(в частности между 32 и 64 битными платформами), на уровне исходного текста(с перекомпиляцией но без измения исходного текста), без виртуальной машины(native)?
Здравствуйте, AlexCab, Вы писали:
AC>Как вы думаете, возможна ли полноценная кросплатформеность(в частности между 32 и 64 битными платформами), на уровне исходного текста(с перекомпиляцией но без измения исходного текста), без виртуальной машины(native)? AC>Спасибо.
Здравствуйте, gandjustas, Вы писали: G>Другое дело что всегда так делать не получится, это требует дополнительных затрат.
О том то и речь, кроме этого есть высокий риск возникновения и шибок связанных с переполнениями, индексами и тп.
то есть при переходе будет необходимо тщательное тестирование и наверняка правка кода (особенно при переходе с 64 на 32).
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Здравствуйте, FR, Вы писали:
FR>А при чем тут нативность, достаточно чтобы базовые типы были жестко фиксированы, например как в D http://www.digitalmars.com/d/2.0/type.html
И я об этом думал, но как быть с индексами и офсетами и тп., а также с оптимальностью кода?
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Здравствуйте, ilnar, Вы писали: I>да. у меня весь проект такой
Проект ведь изначально был кросплатформеный?
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
AC>Как вы думаете, возможна ли полноценная кросплатформеность(в частности между 32 и 64 битными платформами), на уровне исходного текста(с перекомпиляцией но без измения исходного текста), без виртуальной машины(native)? AC>Спасибо.
Смотря, какие допущения ты позволяешь.
Например, если ты додпускаешь, чтобы за кроссплатформенностью следил фреймворк/библиотека, то — да. См. Qt, например. На уровне исходных текстов твои программы абсолютно кроссплатформенны без изменений.
Здравствуйте, AlexCab, Вы писали:
AC>Здравствуйте, ilnar, Вы писали: I>>да. у меня весь проект такой AC>Проект ведь изначально был кросплатформеный?
нет, был на 32битной ОС линух, перелопатил туеву хучу кода, чтобы типы данных практически не отличались, в первую очередь те, что куда-то передаются, записываются на диск, ...
On 10.05.2011 16:28, AlexCab wrote:
> Как вы думаете, возможна ли полноценная кросплатформеность(в частности между 32 > и 64 битными платформами), на уровне исходного текста(с перекомпиляцией но без > измения исходного текста), без виртуальной машины(native)?
Конечно же возможна. Вон сколько очень хорошо переносимых языков
имеется. Хотя бы FORTRAN. Абсолютно переносимый язык, лишь бы
компилятор был.
Здравствуйте, AlexCab, Вы писали:
AC>Как вы думаете, возможна ли полноценная кросплатформеность(в частности между 32 и 64 битными платформами), на уровне исходного текста(с перекомпиляцией но без измения исходного текста), без виртуальной машины(native)?
Что понимается под виртуальной машиной?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, AlexCab, Вы писали:
AC>Здравствуйте, gandjustas, Вы писали: G>>Другое дело что всегда так делать не получится, это требует дополнительных затрат. AC>О том то и речь, кроме этого есть высокий риск возникновения и шибок связанных с переполнениями, индексами и тп.
какого типа переполнения, интересно? все работает. то есть, конечно, проблемы есть, но не у си, а у тех, кто не умеет его готовить.
AC>то есть при переходе будет необходимо тщательное тестирование и наверняка правка кода (особенно при переходе с 64 на 32).
тестирование нужно, конечно. а правка кода нужна если только код кривой как бумеранг. поделюсь опытом портирования своей программы. программа большая и на низком уровне описывает некую мат. модель, которую я долго разрабатывал, шлифовал, а потом сам перестал понимать как она работает. когда приступал к разработке -- спросил у архитектора -- под какими платформами ее планируется использовать? мне сказали -- intel 32. ну я и написал. в древнем коде куча мест, работающих только когда младший байт идет первым и когда sizeof(int) == 4. в более позднем коде размер Int'а уже не играет роли (главное -- не меньше 4х байт), но порядок байт все-таки важен. самый поздний код (мыщъх таки набрался опыта!) нечувствителен и к порядку, т.к. при изменении порядка изменение произойдет в обоих "плечах" конструкций, работающих с памятью и будет по фиг.
однако... программу откомпилировали на 64 бит маке и на 64 бит никсах. и даже древний код работает без переделок, где куча конструкций вида *((unsigned int*)p) == 0x11223344. конечно, так писать нельзя, но когда оно писалось, то предполагалось, что кросс-платформенности не требуется. тем более что оно работает на куче платформ без переделок.
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Здравствуйте, мыщъх, Вы писали: М>какого типа переполнения, интересно? все работает. то есть, конечно, проблемы есть, но не у си, а у тех, кто не умеет его готовить.
Умеющих мало, но думаю даже те кто умеют, будут рады помощи со стороны IDE/компилятора.
М>тестирование нужно, конечно. а правка кода нужна если только код кривой как бумеранг. поделюсь опытом портирования своей программы... М>однако... программу откомпилировали на 64 бит маке и на 64 бит никсах. и даже древний код работает без переделок, где куча конструкций вида *((unsigned int*)p) == 0x11223344. конечно, так писать нельзя, но когда оно писалось, то предполагалось, что кросс-платформенности не требуется. тем более что оно работает на куче платформ без переделок.
С 32 на 64 понятно, а наоборот?
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Здравствуйте, MasterZiv, Вы писали:
MZ>Конечно же возможна. Вон сколько очень хорошо переносимых языков MZ>имеется. Хотя бы FORTRAN. Абсолютно переносимый язык, лишь бы MZ>компилятор был.
Переносимость языка это кошено хорошо, но переносимость программ писаных на нём(а не только отдельных библиотек), лучше.
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Здравствуйте, IT, Вы писали: IT>Что понимается под виртуальной машиной?
JVM, .NET, etc.
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
AC>Как вы думаете, возможна ли полноценная кросплатформеность(в частности между 32 и 64 битными платформами), на уровне исходного текста(с перекомпиляцией но без измения исходного текста), без виртуальной машины(native)?
В общем на сколько я понял, есть два пути:
1.ВМ, в ущерб эфиктивности кода.
2.При помощи зависимых библиотек, он без возможности обратного переноса(со старшей на младшую платформу(с 64 на 32)).
Поправте если не прав.
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Здравствуйте, AlexCab, Вы писали:
AC>Здравствуйте, мыщъх, Вы писали: М>>какого типа переполнения, интересно? все работает. то есть, конечно, проблемы есть, но не у си, а у тех, кто не умеет его готовить. AC>Умеющих мало, но думаю даже те кто умеют, будут рады помощи со стороны IDE/компилятора.
М>>тестирование нужно, конечно. а правка кода нужна если только код кривой как бумеранг. поделюсь опытом портирования своей программы... М>>однако... программу откомпилировали на 64 бит маке и на 64 бит никсах. и даже древний код работает без переделок, где куча конструкций вида *((unsigned int*)p) == 0x11223344. конечно, так писать нельзя, но когда оно писалось, то предполагалось, что кросс-платформенности не требуется. тем более что оно работает на куче платформ без переделок. AC>С 32 на 64 понятно, а наоборот?
а что смущает? все зависит от объемов обрабатываемых данных и их вида.
32 -> 64
во первых, можно тупо скомпилирвать программу 32битной, для 64битного ОС, если тебе не надо с громадными данными работать
во вторых, даже с конструкциями вида *((unsigned int*)p) == 0x11223344 могут случчиться проблемы, если не обеспечивать загрузку всего важного в адресном пространстве до 2Гб, и скорее придется отказаться от -fPIC, DSO
64 -> 32
если нет харкодед трюков, хитростей со свободными верхними битами указателей, ... то пренос с 64 бита на 32 особо не отличается от обратного: интеловский 32 битный процессор поддерживает 64 битные операции, имеются те же CAS2 для замены CAS.
в общем, если появится необходимость, перевести получится.
а если объемы данных небольшие, можно и не особо заморачиваясь перекомпилять код, как мыщъх, и надеяться, что 64битные фичи не используются, и проблем с кросплатформенностью не будет.
Здравствуйте, AlexCab, Вы писали:
AC>В общем на сколько я понял, есть два пути: AC>1.ВМ, в ущерб эфиктивности кода. AC>2.При помощи зависимых библиотек, он без возможности обратного переноса(со старшей на младшую платформу(с 64 на 32)). AC>Поправте если не прав.
Портируемость программы определяется свойствами языка.
ВМ или не ВМ это лишь детали реализации.
Тем более что грань между ВМ и не ВМ крайне размытая.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали: WH>Портируемость программы определяется свойствами языка. WH>ВМ или не ВМ это лишь детали реализации.
Может всё таки свойствами среды в которой будет работать программа?
WH>Тем более что грань между ВМ и не ВМ крайне размытая.
Аргументируйте.
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Здравствуйте, AlexCab, Вы писали:
AC>Здравствуйте, мыщъх, Вы писали: М>>какого типа переполнения, интересно? все работает. то есть, конечно, проблемы есть, но не у си, а у тех, кто не умеет его готовить. AC>Умеющих мало, но думаю даже те кто умеют, будут рады помощи со стороны IDE/компилятора.
а чем ide может помочь?
М>>тестирование нужно, конечно. а правка кода нужна если только код кривой как бумеранг. поделюсь опытом портирования своей программы... М>>однако... программу откомпилировали на 64 бит маке и на 64 бит никсах. и даже древний код работает без переделок, где куча конструкций вида *((unsigned int*)p) == 0x11223344. конечно, так писать нельзя, но когда оно писалось, то предполагалось, что кросс-платформенности не требуется. тем более что оно работает на куче платформ без переделок. AC>С 32 на 64 понятно, а наоборот?
наоборот -- тоже.
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Здравствуйте, мыщъх, Вы писали: М>>>какого типа переполнения, интересно? все работает. то есть, конечно, проблемы есть, но не у си, а у тех, кто не умеет его готовить. AC>>Умеющих мало, но думаю даже те кто умеют, будут рады помощи со стороны IDE/компилятора. М>а чем ide может помочь?
Подсказать опасные места, например.
AC>>С 32 на 64 понятно, а наоборот? М>наоборот -- тоже.
Аргументируйте.
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Здравствуйте, IT, Вы писали: IT>>>Что понимается под виртуальной машиной? AC>>JVM, .NET, etc. IT>Насколько мне известно, в обоих платформах, после джита получается вполне себе нативный код.
Оно то так, но когда программист пишет программу он ориентируется на определённую платформа(среду), реальную(как например программисты С++) или виртуальную(построенную над реальной).
Код писанный для виртуальной платформы в большинстве случаев будет менее эфективен чем написанный для реальной(даже с JIT).
Виртуальная платформа ограждает программиста от деталей реальной, (в частности от необходимости заботится о разрядности(32/64) реальной) таким образом обеспечивая кросплатформеность программы.
Мой вопрос в том, можно ли избавить программиста пишущего под реальную платформу, от необходимости думать о разрядности этой платформы, например чтобы он мог написать скажем библиотеку или
компонент и затем мог использовать её как в 32 разрядных так и 64 разрядных приложениях.
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Здравствуйте, AlexCab, Вы писали:
AC>Переносимость языка это кошено хорошо, но переносимость программ писаных на нём(а не только отдельных библиотек), лучше.
Речь как раз и идет о переносимости программ, написанных на FORTRAN-е. Я уже как-то писал тут о том, как переносил фортрановские исходники с платформы на платформу. Писать их начали еще в 70-е годы в ОС ЕС, а в конце 90-х я их в NT 4 и в полуоси запускал. В UNIX их уже без меня переносили. Только в MS DOS была проблема, связанная с сегментацией памяти, там пришлось к объявлениям массивов добавить атрибут HUGE.
Здравствуйте, Privalov, Вы писали:
P>Здравствуйте, AlexCab, Вы писали:
AC>>Переносимость языка это кошено хорошо, но переносимость программ писаных на нём(а не только отдельных библиотек), лучше.
P>Речь как раз и идет о переносимости программ, написанных на FORTRAN-е. Я уже как-то писал тут о том, как переносил фортрановские исходники с платформы на платформу. Писать их начали еще в 70-е годы в ОС ЕС, а в конце 90-х я их в NT 4 и в полуоси запускал. В UNIX их уже без меня переносили. Только в MS DOS была проблема, связанная с сегментацией памяти, там пришлось к объявлениям массивов добавить атрибут HUGE.
Мне доводилось беседовать с менеджером тех кто статистику на мак переносил. Вот он фортран запомнил так запомнил Все дело в размере наверное.
Здравствуйте, SleepyDrago, Вы писали:
SD>Мне доводилось беседовать с менеджером тех кто статистику на мак переносил. Вот он фортран запомнил так запомнил Все дело в размере наверное.
Интересно, что там такого было в том переносе? Я практически с проблемами не сталкивался. В самом Фортране хватает граблей, но ведь переписывать код не нужно, а потому все грабли остаются нетронутыми. FORTRAN IV поддерживали все компиляторы, которые я видел.
Здравствуйте, AlexCab, Вы писали:
AC>>Как вы думаете, возможна ли полноценная кросплатформеность(в частности между 32 и 64 битными платформами), на уровне исходного текста(с перекомпиляцией но без измения исходного текста), без виртуальной машины(native)? AC>В общем на сколько я понял, есть два пути: AC>1.ВМ, в ущерб эфиктивности кода. AC>2.При помощи зависимых библиотек, он без возможности обратного переноса(со старшей на младшую платформу(с 64 на 32)). AC>Поправте если не прав.
Есть ещё два пути
3. Эмуляция одной машины внутри другой.
4. Прямая трансформация native кода одной платформы в native код другой.
А вообще говоря, если стандарт языка не привязан к конкретной платформе, на платформах есть компиляторы поддерживающие стандарт и программа написана в соответствии со стандартом — то какие проблемы ?
Здравствуйте, Privalov, Вы писали:
P>Здравствуйте, SleepyDrago, Вы писали:
SD>>Мне доводилось беседовать с менеджером тех кто статистику на мак переносил. Вот он фортран запомнил так запомнил Все дело в размере наверное.
P>Интересно, что там такого было в том переносе? Я практически с проблемами не сталкивался. В самом Фортране хватает граблей, но ведь переписывать код не нужно, а потому все грабли остаются нетронутыми. FORTRAN IV поддерживали все компиляторы, которые я видел.
дело было интел — неинтел. Фортран на маках тогда был убитый совсем. А тот что на букву Г тогда был еще совсем не промышленный. У них там были приколы что отладка на границе си-фортран умирала тк символы были в разных системах и отладчик, который они использовали понимал только сишные.
Здравствуйте, AlexCab, Вы писали:
AC>1.ВМ, в ущерб эфиктивности кода.
Как здесь помогает виртуальная машина? При выполнении же всё равно генерится машинный код. Какая разница, получать машинный код непосредственно перед исполнением (jit), или предварительно скомпилив всю программу?
Здравствуйте, AlexCab, Вы писали:
AC>Как вы думаете, возможна ли полноценная кросплатформеность(в частности между 32 и 64 битными платформами), на уровне исходного текста(с перекомпиляцией но без измения исходного текста), без виртуальной машины(native)? AC>Спасибо.
Что касается 32/64, то такая переносимость объективно существует (в обе стороны), потому вопрос о возможности, я полагаю, можно снять. Гораздо сложнее обеспечить переносимость имея в виду необходимость использования API, специфичных для целевых платформ (Windows, Unix, ...).
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, AlexCab, Вы писали:
AC>В общем на сколько я понял, есть два пути: AC>1.ВМ, в ущерб эфиктивности кода.
Вообще говоря, почти для любого языка определяется такая штука, как "исполняющая машина": Фортран-машина, Паскаль-машина, Лисп-машина и т.п. ВМ как отдельный программный комплекс — одна из возможных реализаций исполняющей машины, не более того. В каком-то смысле стандартная библиотека C — тоже ВМ.
AC>2.При помощи зависимых библиотек, он без возможности обратного переноса(со старшей на младшую платформу(с 64 на 32)).
Кто на ком стоял? Если зависимые (ты имеешь в виду платформозависимые?) библиотеки предлагают одинаковый интерфейс, будучи скомпилированными на разных платформах, то возможность переноса никуда не девается. Собственно, простейший пример:
int n = 10;
printf("%d\n", n);
Одинаково работает везде, где встречается компилятор C. При этом совершенно не важно, где именно была написана такая программа: на 32-, на 64-, да хоть на 48-битной машине.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Если нам не помогут, то мы тоже никого не пощадим.
Все дело в размере наверное.
