ОС x64 и 32 битные программы

← →
Игорь Шевченко © (2009-12-04 21:55) [40]

oxffff © (04.12.09 21:49) [39]

> Я собствено не сколько предлагаю, сколько хочу продемонстрировать
> что
> ваш тезис из [22] некорректен для общего случая взаимодействия
> между 32 и 64 бит режимами

а в чем некорректность-то ?

← →
oxffff © (2009-12-04 21:59) [41]

> Игорь Шевченко © (04.12.09 21:55) [40]

В том, что трансляции операндов(читай неявное приведение типов) необязательна. :)

← →
Игорь Шевченко © (2009-12-04 22:02) [42]

oxffff © (04.12.09 21:59) [41]

То есть, тебе никто не мешает написать пример взаимодействия 32-х и 64-битного кода без всяких дополнительных преобразований, верно ? Есть два процесса, разной разрядности, они могут свободно вызывать функции друг друга, правильно ? :)

← →
oxffff © (2009-12-04 22:10) [43]

> Игорь Шевченко © (04.12.09 22:02) [42]

Не передергивайте. :)

В данный момент мы говорим о взаимодействии ядра и приложений 3 кольца.
Где можно подсунуть приложению нужный интерфейс.

← →
Inovet © (2009-12-04 22:22) [44]

> [43] oxffff © (04.12.09 22:10)
> В данный момент мы говорим о взаимодействии ядра и приложений 3 кольца.
> Где можно подсунуть приложению нужный интерфейс.

На каком-то этапе придётся преобразовать, или, как ИШ говорит, две ОС на одном железе с синхронизатором.

← →
oxffff © (2009-12-04 22:25) [45]

> или, как ИШ говорит, две ОС на одном железе с синхронизатором.

Где говорит? :)

← →
boa_kaa © (2009-12-04 22:26) [46]

> oxffff © (04.12.09 22:25) [45]
> Где говорит? :)

поздравляю! :)

← →
oxffff © (2009-12-04 22:28) [47]

> boa_kaa © (04.12.09 22:26) [46]
>
> > oxffff © (04.12.09 22:25) [45]
> > Где говорит? :)
>
> поздравляю! :)

Спасибо.

← →
Игорь Шевченко © (2009-12-04 22:34) [48]

oxffff © (04.12.09 22:10) [43]

Отнюдь не передергиваю.
Неважно, ядерный процесс имеет другую разрядность, или неядерный. Суть спора в том, требуется ли некое преобразование (трансляция) при взаимодействии 32-х битового и 64-разрядного кода. Для простого примера можно повызывать функции из одного процесса в другом, вроде наиболее простой способ взаимодействия. Пусть они будут друг другу доступны (страницы обоих процессов отображаются на каждое адресное пространство).

Сделаешь пример ?

← →
Inovet © (2009-12-04 22:37) [49]

> [46] boa_kaa © (04.12.09 22:26)
>
> > oxffff © (04.12.09 22:25) [45]
> > Где говорит? :)
>
> поздравляю! :)

Э... Дык, всю ветку вроде.:)

← →
oxffff © (2009-12-04 22:53) [50]

> Игорь Шевченко © (04.12.09 22:34) [48]
> oxffff © (04.12.09 22:10) [43]
>
> Отнюдь не передергиваю.
> Неважно, ядерный процесс имеет другую разрядность, или неядерный.
> Суть спора в том, требуется ли некое преобразование (трансляция)
> при взаимодействии 32-х битового и 64-разрядного кода. Для
> простого примера можно повызывать функции из одного процесса
> в другом, вроде наиболее простой способ взаимодействия.
> Пусть они будут друг другу доступны (страницы обоих процессов
> отображаются на каждое адресное пространство).
>
> Сделаешь пример ?

А я думаю самый сложный пример. И не выполнимый.
Да все бы хорошо, но как мне заставить выполняться 64 бит в 32 битном compability mode, если я не операционная система? Если и инструкции по разному трактуются. И у меня прав не хватит.
Разница в том, что мы обсуждали обмен данными, а не обмен кодом.
Так что пример я не смогу сделать в силу его заведомой невыполнимости. :)

← →
Alx2 © (2009-12-04 22:56) [51]

С сего момента - схватка мастеров.

← →
Игорь Шевченко © (2009-12-04 23:03) [52]

oxffff © (04.12.09 22:53) [50]

> Разница в том, что мы обсуждали обмен данными, а не обмен
> кодом.

Тут я, честно говоря, не понял. Обмен данными - это соглашение между обменивающимися, если они соглашаются, что они будут обмениватся структурой вида
type
TFoo = packed record
bar1: ULONG32;
bar2: ULONG32;
bar3: ULONG64;
end;

то какая бы разрядность не была у обменивающихся сторон, от 16 до 64, они всегда будут меняться тем, о чем договорились.

Но просто так вызвать 32-х битному процессу одну и ту же функцию вида
foo (arg1: ULONG; arg2: ULONG)
из 64-битного процесса и из 32-х битного не получится.

Или 32-х битный процесс должен гарантировано знать, что он вызывает именно функцию в 64-битном процессе (и только в нем). В этом случае трансляция данных не требуется.

← →
GDI+ (2009-12-04 23:03) [53]

> oxffff © (04.12.09 22:53) [50]

Извините, насколько я понял, вы хотите вместо проксирования вызовов сделать две копии системных сервисов для 32-бит и 64-бит, который как-то будут синхронизироваться?

Если да, то я против. Во первых в 64-битной системе итак куча багов, а здесь еще будут баги некорректной синхронизации. Во вторых 32-битный режим умирающий в линейке Windows(это как мертвый Win16). Вот вы сделаете так, а потом когда останется одно 32-битное приложение на 100 компьютеров то кто будет оплачивать накладные расходы на 32-битную подержку.

Вон в том же Win2008 WOW64 устанавливается только вручную(по требованию), а не по умолчанию. И это правильно.

PS
Я не теоретик, я Практик.

> Игорь Шевченко © (04.12.09 23:03) [52]

Нельзя вызвать через procedure64(someparam) 64 битный код из 32 битного и наоборот. Поскольку сами команды могут работают по разному и этот код вообще может некорректен в режиме вызывающего.
То есть если мы и положем данные как нужно, но код просто не будет работать так как он будет работать в своем режиме.
Если вызов происходит через int 2e или 64 бит операционной системой 32 битного кода, то помимо того что она сложит правильно данные, он и сможет вызвать в код в режиме для которого он предназначен, поскольку ОС может переключить режим.

Поэтому 32 битный код должен быть вызван в режиме для которого он написан и данные должный быть сложены так как он ожидает. Это может быть compability mode или protected mode.

32 битный код может вызвать функцию 64 битного, но он должен быть способен переключиться в него. Это тоже ОС.

В случае системных вызовов эти переключения делаются операционной системой. Поэтому считаю что нельзя так обобщить наш спор(для меня это диалог. И разминка для мозга). :)

> GDI+ (04.12.09 23:03) [53]

Я собственно не о Microsoft и ее решении. Я могу ошибаться,но мне представляются что для Microsoft просто пришла эра 64 бит, с возможностью выполнения 32 бит(но в качестве неосновной опции). Они сделали так, что возможность выполнения есть(пусть ценой некоторых затрат), но главное есть.
Уверен в Microsoft, других ОС придумали бы и другой способ, если бы стояла такая задача.

> для меня это диалог

Диалог, так диалог :) В любом случае какое-то посредничество для взаимодействия разноразрядных процессов требуется, я надеюсь, все стороны с этом выводом согласны. Я почему говорю про трансляцию, потому что 32-х битные программы (в случае Windows, Linux, вероятно еще каких-то систем), обычно являются унаследованными, следовательно, разработаны без заведомого расчета на работу с 64-битным ядром. Вот их вызовы и надо транслировать, включая преобразование данных.

> Вот их вызовы и надо транслировать, включая преобразование
> данных.

Что по поводу интероперабельности между разнорежимными процессами без преобразований.
Мне кстати хотелось сразу предложить способ в виде разделяемых страниц у процессов(для обмена данными) и вызове через передачу сообщений окнам, как самое простое. Таким образом мы достигаем интероперабельности между разнорежимными процессами. А данные трактуем так предписывает принятое сообщение.
Здесь мы может обойтись без трансляции. Поскольку сообшения показывают нам как трактовать данные. ;)

oxffff © (04.12.09 23:40) [57]

Разделяемость страниц безусловно есть - это объекты Section (в Windows) или результат вызова mmap в Linux, каждый из таких вызовов гарантирует создание набора разделяемых между процессами страниц, а что до инициации взаимодействия, то сообщения между окнами не самый прямой способ, обычно каналы того или иного вида используются (в линуксе-то точно, каналы да сигналы - самый простой способ межпроцессного взаимодействия).

ОС x64 и 32 битные программы Найти похожие ветки