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

← →
Keep (2009-11-30 18:46) [0]

Мы тут поспорили с одним товарищем.
Он грит что на ОС x64 32 битные проги работают через эмулятор и иза заэтого работают медленнее и глючней. и могут даже не запускаться.

Насколько утверджение медлненее и остальные верно? Может кто то знает больше тех. деталей?

← →
GDI+ (2009-11-30 18:54) [1]

> Keep (30.11.09 18:46)

WOW64
http://support.microsoft.com/default.aspx/kb/896456/

← →
GDI+ (2009-11-30 18:55) [2]

Отпощу, чтоб избежать 8000 страниц флуда

Вопросы производительности приложений
Подсистема WOW64 создает 32-разрядную среду в версиях Windows Server 2003 для архитектуры x64 и в Windows XP Professional x64 Edition. Некоторые 32-разрядные программы могут выполняться в этих операционных системах медленнее, чем в 32-разрядных версиях Windows Server 2003 и Windows XP. Например, 32-разрядная программа может выполняться в Windows XP Professional x64 Edition медленнее, чем в Microsoft Windows XP Professional. При этом некоторые 32-разрядные программы, требующие значительных ресурсов памяти, могут демонстрировать повышение быстродействия в версиях Windows Server 2003 для архитектуры x64 и Windows XP Professional x64 Edition. Это повышение быстродействия связано с тем, что версии Windows Server 2003 для архитектуры x64 и Windows XP Professional x64 Edition поддерживают больший объем физической памяти, чем 32- разрядные версии Windows Server 2003 и Windows XP Professional.

← →
Игорь Шевченко © (2009-11-30 19:14) [3]

> Может кто то знает больше тех. деталей?

Гугль обычно знает. Но туда очень трудно попасть

← →
DVM © (2009-11-30 19:29) [4]

> Он грит что на ОС x64 32 битные проги работают через эмулятор
> и иза заэтого работают медленнее и глючней. и могут даже
> не запускаться.

Медленнее, но самую малость. Что до глючности - это как правило следствие того, что эти программы изначально были спроектированы не совсем правильно.
32 разрядные программы выполняются в некой песочнице и большинство проблем возникает именно с этим. В песочнице доступ к ряду системных паок и ключей реестра перенаправлен в их "песочные" заменители.

← →
GDI+ (2009-11-30 19:36) [5]

> DVM © (30.11.09 19:29) [4]
>
> Медленнее, но самую малость.

Даже еще уточню. Медленнее выполняются вызовы к системным API, так как вызов идёт через прокси-библиотеку wow64.dll. Все внутренние функции программы и работа с 32-битными Dll идёт с той же производительностью.

← →
TUser © (2009-12-01 08:45) [6]

Это все теория. На практике 64 ставят часто именно ради поддержки большого объема памяти, то есть на не самое гнилое железо. Ну и производительность соотвественно

:)

← →
DVM © (2009-12-01 11:07) [7]

> TUser ©

> На практике 64 ставят часто именно ради поддержки большого
> объема памяти, то есть на не самое гнилое железо. Ну и производительность
> соотвественно

Между прочим, есть процессоры с поддержкой x64 весьма и весьма слабые. Например мобильные процессоры Intel ULV

← →
Rouse_ © (2009-12-01 20:40) [8]

> могут даже не запускаться.

Истину глаголит, но есть нюансы, которые не понятно из-за чего на одной машине прерывают работу программы, а на другой аналогичной - все норм.
В частности с CreateProcess и CreateFile были замечены непонятные редковстречающиеся глюки

← →
turbouser © (2009-12-01 20:59) [9]

> Rouse_ © (01.12.09 20:40) [8]

Может дело в драйверах?

← →
Rouse_ © (2009-12-01 21:04) [10]

> Может дело в драйверах?

С дровами проще - 32 бита под 64 не сядет хоть ты тресни. Ситуация банальней, открытие файла не работает, причем ошибка идет вообще не понятная, или на стэке выпадаем или функция таки выполняется но код возврата из разряда OLE ошибок (с оле префиксом). Причем на 99 процентах тачек все работает, а с остальными приходится выкручиваться.

← →
tesseract © (2009-12-02 10:17) [11]

> Причем на 99 процентах тачек все работает, а с остальными
> приходится выкручиваться.

Lower/UpperFilters вроде мозг взрывает. Встречался с несовместимыми с х64 драйверами. В принципе под XP64 они все работают через опу, то хард неожиданно отвалится, то сидюк.

← →
oxffff © (2009-12-02 11:14) [12]

> Keep (30.11.09 18:46)
> Мы тут поспорили с одним товарищем.
> Он грит что на ОС x64 32 битные проги работают через эмулятор
> и иза заэтого работают медленнее и глючней. и могут даже
> не запускаться.

Compatibility mode, a submode of long mode, allows system
software to implement binary compatibility with existing 16-bit
and 32-bit x86 applications. It allows these applications to run,
without recompilation, under 64-bit system software in long
mode, as shown in Table 1-1 on page 13.
In compatibility mode, applications can only access the first
4 Gbytes of virtual-address space. Standard x86 instruction
prefixes toggle between 16-bit and 32-bit address and operand
sizes.
Compatibility mode, like 64-bit mode, is enabled by system
software on an individual code-segment basis. Unlike 64-bit
mode, however, segmentation functions the same as in the
legacy-x86 architecture, using 16-bit or 32-bit protected-mode
semantics. From an application viewpoint, compatibility mode
looks like a legacy protected-mode environment. From a
system-software viewpoint, the long-mode mechanisms are used
for address translation, interrupt and exception handling, and
system data-structures.

То есть никаких эмуляторов быть не должно. Поддерживается аппаратно.

← →
RWolf © (2009-12-02 14:37) [13]

Вот чего лично я не пойму — раз для 32-бит кода в x64 всё равно сделали режим совместимости, зачем было городить в 64-битном коде такой громоздкий формат команд? они же все 64-бит инструкции реализовали через префиксы x86, через это имеем огромные бинарники, плохое время выборки и забитый кэш инструкций.

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

> То есть никаких эмуляторов быть не должно. Поддерживается
> аппаратно

Вызовы операционной системы аппаратно не поддерживаются. У Руссиновича в главе 3 про Wow64 подробно описано.

← →
oxffff © (2009-12-02 15:06) [15]

> Игорь Шевченко © (02.12.09 14:42) [14]
>
> > То есть никаких эмуляторов быть не должно. Поддерживается
>
> > аппаратно
>
>
> Вызовы операционной системы аппаратно не поддерживаются.
> У Руссиновича в главе 3 про Wow64 подробно описано.

Почему сразу ассоциации с реализацией в Windows?
Я собственно привел выдержку из документации по реализации AMD64 architecture. То что сделал или не сделал Microsoft это из другой серии.

← →
Игорь Шевченко © (2009-12-02 15:26) [16]

oxffff © (02.12.09 15:06) [15]

> Почему сразу ассоциации с реализацией в Windows?

По предмету темы, вообще-то.

Кроме того, процессор работает в разных режимах, из твоей же цитаты видно, что "From a system-software viewpoint, the long-mode mechanisms are used for address translation, interrupt and exception handling, and
system data-structures."

А для трансляции нужен перехват и собственно, трансляция.

← →
oxffff © (2009-12-02 15:55) [17]

> Игорь Шевченко © (02.12.09 15:26) [16]
> oxffff © (02.12.09 15:06) [15]
>
>
> > Почему сразу ассоциации с реализацией в Windows?
>
>
> По предмету темы, вообще-то.

Где упоминание о windows?

Собствено то как сделано в windows, является решением программистов Microsoft.

← →
oxffff © (2009-12-02 15:59) [18]

> Игорь Шевченко © (02.12.09 15:26) [16]
> oxffff © (02.12.09 15:06) [15]
>
>
> > Почему сразу ассоциации с реализацией в Windows?
>
>
> По предмету темы, вообще-то.
>
> Кроме того, процессор работает в разных режимах, из твоей
> же цитаты видно, что "From a system-software viewpoint,
> the long-mode mechanisms are used for address translation,
> interrupt and exception handling, and
> system data-structures."
>
> А для трансляции нужен перехват и собственно, трансляция.
>

Вообше то речь идет о трансляции адресов, а не о трансляции вызовов.

← →
Игорь Шевченко © (2009-12-02 16:09) [19]

oxffff © (02.12.09 15:59) [18]

Зачем ты отдельные слова выделяешь ? Так больше нравится ? :)

← →
oxffff © (2009-12-02 16:11) [20]

Если верить wiki :)

http://en.wikipedia.org/wiki/WoW64

Despite its outwardly similar appearance on all versions of 64-bit Windows, WOW64"s implementation varies depending on the target processor architecture. For example, the version of 64-bit Windows developed for the Intel Itanium 2 processor (known at Microsoft as IA-64 architecture) uses Wow64win.dll to set up the emulation of x86 instructions within the Itanium 2"s unique instruction set. This emulation is a more computationally expensive task than the Wow64win.dll"s functions on the x86-64 (x64) architecture, which switches the processor hardware from its 64-bit mode to compatibility mode when it"s time to execute a 32-bit thread, and then handles the switch back to 64-bit mode. No emulation is required for WOW64 on x86-64 (x64).

Однако у меня нет под рукой Руссиновича. Но я предполагаю, что вы упомянули о трансляции разного представляния типов ядра из 64 в 32 и обратно Так поступили в Microsoft.

Однако ничего не мешает для обработки зависимых о типа данных
сделать копии ядерных подсистем в другом случае как вариант и избежать транляции.

← →
oxffff © (2009-12-02 16:18) [21]

> Игорь Шевченко © (02.12.09 16:09) [19]
> oxffff © (02.12.09 15:59) [18]
>
> Зачем ты отдельные слова выделяешь ? Так больше нравится
> ? :)

Я лишь показал, что речь шла о трансляции адресов. И связи между трансляцией адресов и перехватом нет.

см. документацию

In long mode, the effects of segmentation depend on whether
the processor is running in compatibility mode or 64-bit mode:
&#56256;&#56452; In compatibility mode, segmentation functions just as it
does in legacy mode, using legacy 16-bit or 32-bit protected
mode semantics.

Code-Segment Descriptors. The AMD64 architecture defines a new
code-segment descriptor attribute, L (long). In compatibility
mode, the processor treats code-segment descriptors as it does
in legacy mode,

In compatibility mode, the processor treats data-segment
descriptors as it does in legacy mode. Compatibility mode
ignores the high 32 bits of base address in the FS and GS
segment descriptors when calculating an effective address.

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

oxffff © (02.12.09 16:11) [20]

А я где-то говорил про эмуляцию ? :) Вот новость. Про переключение процессора говорил, это и в Windows и в Linux происходит, про трансляцию между 64-битными и 32-х битными процессами говорил, а про эмуляцию вроде не упонимал.

Собственно, про разные режимы процессора довольно подробно у Intel написано (я IA-32e имею в виду, не Itanuim)

"Intel 64 architecture adds IA-32e mode. IA-32e mode has two sub-modes.
These are:
• Compatibility mode (sub-mode of IA-32e mode) — Compatibility mode
permits most legacy 16-bit and 32-bit applications to run without re-compilation
under a 64-bit operating system. For brevity, the compatibility sub-mode is
referred to as compatibility mode in IA-32 architecture. The execution
environment of compatibility mode is the same as described in Section 3.2.
Compatibility mode also supports all of the privilege levels that are supported in
64-bit and protected modes. Legacy applications that run in Virtual 8086 mode or
use hardware task management will not work in this mode.
Compatibility mode is enabled by the operating system (OS) on a code segment
basis. This means that a single 64-bit OS can support 64-bit applications running
in 64-bit mode and support legacy 32-bit applications (not recompiled for
64-bits) running in compatibility mode.

Compatibility mode is similar to 32-bit protected mode. Applications access only
the first 4 GByte of linear-address space. Compatibility mode uses 16-bit and 32-
bit address and operand sizes. Like protected mode, this mode allows applications
to access physical memory greater than 4 GByte using PAE (Physical
Address Extensions).

• 64-bit mode (sub-mode of IA-32e mode) — This mode enables a 64-bit
operating system to run applications written to access 64-bit linear address
space. For brevity, the 64-bit sub-mode is referred to as 64-bit mode in IA-32
architecture.
64-bit mode extends the number of general purpose registers and SIMD
extension registers from 8 to 16. General purpose registers are widened to 64
bits. The mode also introduces a new opcode prefix (REX) to access the register
extensions. See Section 3.2.1 for a detailed description.
64-bit mode is enabled by the operating system on a code-segment basis. Its
default address size is 64 bits and its default operand size is 32 bits. The default
operand size can be overridden on an instruction-by-instruction basis using a REX
opcode prefix in conjunction with an operand size override prefix.
REX prefixes allow a 64-bit operand to be specified when operating in 64-bit
mode. By using this mechanism, many existing instructions have been promoted
to allow the use of 64-bit registers and 64-bit addresses"

То есть, трансляция между этими двумя режимами требуется независимо от операционной системы.

← →
oxffff © (2009-12-02 16:34) [23]

> Игорь Шевченко © (02.12.09 16:21) [22]

> То есть, трансляция между этими двумя режимами требуется
> независимо от операционной системы.

Почему Ваш вывод однозначен?

А как насчет варианта такого

Два копии функциональности ядра одна работает с 64 операндами, вторая работает с 32 операндами.
Переключатель задач устанавливает разные IDT для нужной реализации через через шлюз вызова INT 2e при переключении задачи?

← →
Игорь Шевченко © (2009-12-02 16:40) [24]

oxffff © (02.12.09 16:34) [23]

> Почему Ваш вывод однозначен?

Грубо, если в 64-х битном процессе есть функция foo (int* bar1, int* bar2), то она будет ожидать в стеке двух 64-битных значений. Если она вызывается из 32-х битного процесса, то в стеке будет находится два 32-х битных значения.

Насчет двух копий функциональности ядра - не думаешь ли ты, что потери на синхронизацию двух ядер с одним набором аппаратных ресуров потребуют больше времени, чем преобразование при системных вызовах ?

← →
oxffff © (2009-12-02 22:11) [25]

> Игорь Шевченко © (02.12.09 16:40) [24]
> oxffff © (02.12.09 16:34) [23]
>
>
> > Почему Ваш вывод однозначен?
>
>
> Грубо, если в 64-х битном процессе есть функция foo (int*
> bar1, int* bar2), то она будет ожидать в стеке двух 64-битных
> значений. Если она вызывается из 32-х битного процесса,
> то в стеке будет находится два 32-х битных значения.
>
> Насчет двух копий функциональности ядра - не думаешь ли
> ты, что потери на синхронизацию двух ядер с одним набором
> аппаратных ресуров потребуют больше времени, чем преобразование
> при системных вызовах ?

Где потери? На какую синхронизацию?

Грубо так

IWin64SubSystem=interface
["{575E9561-758C-4C1C-95D8-3620E262E1C1}"]
function CoreFuncionNumber1(Param1:Int64):int64;
end;

IWin32SubSystem=interface
["{731B7DD6-0315-4CD9-8F44-DF17B980D38B}"]
function CoreFuncionNumber1(Param1:Int32):int32;
end;

TShedulerExecTask=TProc;

TWindows64=class(TInterfacedObject,Win64SubSystem,Win32SubSystem)
function CoreFuncionNumber1(Param1:Int64):int64;overload;
function CoreFuncionNumber1(Param1:Int32):int32;overload;
end;

procedure TForm4.FormCreate(Sender: TObject);
var Windows64:TWindows64;
Win64:IWin64SubSystem;
Win32:IWin32SubSystem;
begin
Windows64:=TWindows64.Create;
Win64:=Windows64;
Win32:=Windows64;
Task32:=procedure
begin
Win32.CoreFuncionNumber1(32);
end
Task64:=procedure
begin
Win64.CoreFuncionNumber1(64);
end
end;

function TWindows64.CoreFuncionNumber1(Param1: Int64): int64;
begin
//
Driver64.call64;
end;

function TWindows64.CoreFuncionNumber1(Param1: Int32): int32;
begin
Driver32.call32 или Driver64.call32
end;

Теперь собственно о синхронизации. Работа с аппаратными ресурсами нормально синхронизируется. Вы не задумывались, как это потоки на разных ядрах процессора умудряются вызывать один и тот же драйвер и при этом не кофликтовать друг с другом( IRQL, Spinlock ...).
Предлагается поступить и в этом случае аналогично.

← →
oxffff © (2009-12-02 22:18) [26]

> Теперь собственно о синхронизации. Работа с аппаратными
> ресурсами нормально синхронизируется. Вы не задумывались,
> как это потоки на разных ядрах процессора умудряются вызывать
> один и тот же драйвер и при этом не кофликтовать друг с
> другом( IRQL, Spinlock ...).
> Предлагается поступить и в этом случае аналогично.

Более того предусмотрено даже разделение аппаратных ресурсов разными драйверами. Например Shared IRQ. Об этом все там же у Соломона или в DDK.

← →
Игорь Шевченко © (2009-12-02 23:13) [27]

> Например Shared IRQ.

Это разные устройства, а не разные драйверы. Прерывание будет приходить в процессор, кто-то должен опросить устройства на предмет, кто их них конкретно выставил уровень на шине прерывания. Кто будет заниматься опросом - 32 бита или 64 ?

> Где потери? На какую синхронизацию?

На синхронизацию двух ядер с одним железом. Память, процессорное время, устройства...

> Работа с аппаратными ресурсами нормально синхронизируется.
> Вы не задумывались, как это потоки на разных ядрах процессора
> умудряются вызывать один и тот же драйвер и при этом не
> кофликтовать друг с другом

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

← →
oxffff © (2009-12-03 00:04) [28]

> Игорь Шевченко © (02.12.09 23:13) [27]
>
> > Например Shared IRQ.
>
>
> Это разные устройства, а не разные драйверы. Прерывание
> будет приходить в процессор, кто-то должен опросить устройства
> на предмет, кто их них конкретно выставил уровень на шине
> прерывания. Кто будет заниматься опросом - 32 бита или 64
> ?

Ну и разные драйвера. :)
Кто будет опрашивать. Например оба драйвера.
Или некий общий компонент, который осуществляет обработку ответов устройства. Хотя в данном случае имеет смысл сохранить драйвера низкого уровня в единственном экземпляре в одном формате (PDC вроде назывались) от драйверов высокого уровня, которые можно продублировать.

>
>
> > Где потери? На какую синхронизацию?
>
>
> На синхронизацию двух ядер с одним железом. Память, процессорное
> время, устройства...

Повышение IRQL и использование spinlock это стандартные механизмы синхронизации. В чем заключается дополнительная синхронизация?
Конкретный пример.

>
>
> > Работа с аппаратными ресурсами нормально синхронизируется.
>
> > Вы не задумывались, как это потоки на разных ядрах процессора
>
> > умудряются вызывать один и тот же драйвер и при этом не
>
> > кофликтовать друг с другом
>
>
> Так вся синхронизация процессоров в одном коде - куда тут
> нормальнее ?
> Нужен одному из ядер процессора монопольный доступ к ресурсам,
> захватывает грубо говоря, мьютекс (неважно, как он на самом
> деле выглядит, спинлок, критическая секция, мутант), быстро
> работает и отдает обратно. А в твоем случае потребуется
> надсмотрщик над двумя разными ядрами, который будет их разруливать,
> переключать процессор в нужный режим, и т.п.

Переключение режимов не нужно. Вы же можете написать mov DWORD PTR или mov WORD PTR. Все остальное штатно используя повышение IRQL или spinlock.

Также не забывайте рассмотреть также и случай, когда системная функция windows не просто транслирует данные драйверу, а например выполняет действия над данными и результат шлет драйверу в виде команды и данных в нужном драйверу формате. Поэтому действия по преобразованию данных будут лишними.

> oxffff © (03.12.09 00:04) [28]
>
> > Игорь Шевченко © (02.12.09 23:13) [27]
> >
> > > Например Shared IRQ.
> >
> >
> > Это разные устройства, а не разные драйверы. Прерывание
>
> > будет приходить в процессор, кто-то должен опросить устройства
>
> > на предмет, кто их них конкретно выставил уровень на шине
>
> > прерывания. Кто будет заниматься опросом - 32 бита или
> 64
> > ?
>
>
> Ну и разные драйвера. :)
> Кто будет опрашивать. Например оба драйвера.
> Или некий общий компонент, который осуществляет обработку
> ответов устройства. Хотя в данном случае имеет смысл сохранить
> драйвера низкого уровня в единственном экземпляре в одном
> формате (PDC вроде назывались) от драйверов высокого уровня,
> которые можно продублировать.

Также возможно например указать системе текущий драйвер обработчик прерывания от данного устройства, который последним отправил запрос.

> Переключение режимов не нужно. Вы же можете написать mov
> DWORD PTR или mov WORD PTR.

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

> Игорь Шевченко © (03.12.09 00:35) [30]
>
> > Переключение режимов не нужно. Вы же можете написать mov
>
> > DWORD PTR или mov WORD PTR.
>
>
> Я сильно извиняюсь, но процессор в разных режимах работает
> слегка по-разному. Я в одном из постов выше выдержку из
> Intel-овского мануала приводил с общим набором отличий,
> к тому же, есть разница и в обработке команд. Некоторые
> вообще не обрабатываются :) То есть, одним PTR не обойдешься.
> ..

И как это относится к ограничениям на DWORD PTR и WORD PTR или
QWORD PTR?
А то по вашим словам получается, находясь в LONG (64 bit) режиме мы не может обработать операнды менее 64 байт.
Опровержение из приведенной вами выдержки это

default address size is 64 bits and its default operand size is 32 bits. The default operand size can be overridden on an instruction-by-instruction basis using a REX
opcode prefix in conjunction with an operand size override prefix.

На всякий случай привожу выдержку из документации AMD, которая опровергает ваше утверждение.

64-bit mode, a submode of long mode, provides support for 64-
bit system software and applications by adding the following
new features:

The mode is enabled by the system software on an individual
code-segment basis. Although code segments are used to enable
and disable 64-bit mode, the legacy segmentation mechanism is
largely disabled. Page translation is required for memory
management purposes. Because 64-bit mode supports a 64-bit
virtual-address space, it requires 64-bit system software and
development tools.
In 64-bit mode, the default address size is 64 bits, and the
default operand size is 32 bits. The defaults can be overridden
on an instruction-by-instruction basis using instruction
prefixes. A new REX prefix is introduced for specifying a 64-bit
operand size and the new registers.

Operand-Size Overrides. In 64-bit mode, the default operand size is
32 bits. A REX prefix can be used to specify a 64-bit operand
size. Software uses a legacy operand-size (66h) prefix to toggle
to 16-bit operand size. The REX prefix takes precedence over
the legacy operand-size prefix.

> операнды менее 64 байт.

64 бит. :)

oxffff © (03.12.09 08:37) [31]

Я не понимаю, ты о чем ? И у Intel и у AMD для 64-битных процессов процессор работает в другом режиме, чем для 32-битных.

Для того, чтобы этим процессам взаимодействовать, процессор надо переключать из одного режима в другой.

> Игорь Шевченко © (04.12.09 12:01) [33]

Так они и так переключаются. Иначе как они работать будут?
Для этого и придумали compatibility mode.

Legacy 32 приложение в ring 3 работает в compatibility mode,
Compatibility mode, like 64-bit mode, is enabled by system
software on an individual code-segment basis. In compatibility mode, applications can only access the first 4 Gbytes of virtual-address space. Unlike 64-bit mode, however, segmentation functions the same as in the
legacy-x86 architecture, using 16-bit or 32-bit protected-mode
semantics. From an application viewpoint, compatibility mode
looks like a legacy protected-mode environment. И т.д.

In compatibility mode, the processor treats code-segment descriptors as it does
in legacy mode, with the exception that the processor
recognizes the L attribute. If a code descriptor with L=1 is
loaded in compatibility mode, the processor leaves
compatibility mode and enters 64-bit mode.

Однако когда мы вызываем системый сервис (-> Ring 0)из сompatibility mode в 64 bit mode Таблица системых функций режима ядра содержит указатели на функции обрабатывающие 32 и 16 операнды в 64 режиме.

Однако когда мы вызываем системый сервис via int 2e(-> Ring 0)в родном 64 bit режиме Таблица системых функций режима ядра содержит указатели на функции обрабатывающие 64 операнды в 64 режиме.

То есть эти таблицы меняются для разных процессов 32 или 64.
Получаются перегруженные сервисы via int 2e(overloads).
С той лишь разницей, что операнды обрабатываются внутри системого сервиса без преобразования, т.е. без penalty.

oxffff © (04.12.09 14:53) [34]

А кто будет осуществлять арбитраж двух различных наборов сервисов ? Пятое колесо в телеге ?

> Игорь Шевченко © (04.12.09 15:59) [35]
> oxffff © (04.12.09 14:53) [34]
>
> А кто будет осуществлять арбитраж двух различных наборов
> сервисов ? Пятое колесо в телеге ?

Кто то. Операционная система. При переключении на 32 битный поток шлюз вызова 2e настраивается на обращение к одной таблице. При переключении на 64 бит поток на обращение к другой таблице сервисов.

oxffff © (04.12.09 21:27) [36]

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

> Игорь Шевченко © (04.12.09 21:36) [37]
> oxffff © (04.12.09 21:27) [36]

По сути не две копии операционной системы. А две копии сервисов, обрабатывающих операнды разных режимов. Но! это не две копии операционной системы.

> Игорь Шевченко © (04.12.09 21:36) [37]
> Правильно ?

Я собствено не сколько предлагаю, сколько хочу продемонстрировать что
ваш тезис из [22] некорректен для общего случая взаимодействия между 32 и 64 бит режимами. Вот и все.
Я смотрел документацию amd system programming. Я не нашел, что должна быть именно такая реализация как сделал Microsoft.

Вы покажите где в документации Intel или AMD, написано о том, что вы утверждаете в [22]. То есть, что

Игорь Шевченко ©
трансляция между этими двумя режимами требуется независимо от операционной системы.

Пожалуйста номер документа, версию и страницу где почитать.

oxffff © (04.12.09 21:49) [39]

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

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

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