64-битные приложения и встроенная сборка

Я использую Visual С++ 2010 для разработки 32-битных оконных приложений. Есть что-то, что я действительно хочу использовать встроенную сборку. Но я просто понял, что визуальный С++ не поддерживает встроенную сборку в 64-битных приложениях. Поэтому перенос на 64-битный в будущем является большой проблемой.

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

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

Ответ 1

Visual C++ не поддерживает встроенную сборку для процессоров x64 (или ARM), потому что обычно использование встроенной сборки - плохая идея.

Обычно компиляторы производят лучшую сборку, чем люди.
Даже если вы можете создать лучшую сборку, чем компилятор, использование встроенной сборки обычно побеждает оптимизаторы кода любого типа. Конечно, ваш код, оптимизированный для рук, может быть быстрее, но тот факт, что код вокруг него не может быть оптимизирован, обычно приводит к более медленной программе в целом.
Встроенные функции компилятора доступны практически во всех основных компиляторах, которые позволяют получить доступ к расширенным функциям ЦП (например, SSE) способом, совместимым с языками C и C++, и не наносят ущерба оптимизатору.

Я хотел бы знать, есть ли шанс, что 32-битные приложения ВСЕ должны быть обновлены до 64-битных в будущем.

Это зависит от вашей целевой аудитории. Если вы ориентируетесь на серверы, то да, разумно разрешить пользователям не устанавливать подсистему WOW64, потому что это сервер - вы знаете, что, вероятно, не будет выполняться слишком много 32-битного кода. Я полагаю, что Windows Server 2008 R2 уже допускает это в качестве опции, если вы устанавливаете его как экземпляр "ядра сервера".

Поскольку производительность не имеет значения для моего приложения, использование дополнительных 64-битных регистров для меня не имеет значения. Есть ли другие причины, по которым 32-битное приложение должно быть обновлено до 64-битного в будущем?

64 бит не имеет ничего общего с регистрами. Это связано с размером адресуемой виртуальной памяти.

Будет ли процесс 64-битного приложения отличаться от процесса 32-битного приложения помимо того, что 64-битное приложение использует некоторые регистры/инструкции, уникальные для 64-битных процессоров?

Более вероятный. 32-разрядные приложения ограничены в том, что они не могут отображать в память вещи размером более ~ 2 ГБ одновременно. 64-битные приложения не имеют этой проблемы. Даже если они не используют более 4 ГБ физической памяти, возможность адресации более 4 ГБ виртуальной памяти полезна для отображения файлов на диске в память и тому подобное.

Мое приложение должно взаимодействовать с другими компонентами ОС, например, драйверами, которые, как я знаю, должны быть 64-битными в 64-битных окнах. Будет ли мое 32-битное приложение совместимо с ними?

Это полностью зависит от того, как вы общаетесь с этими драйверами. Если это происходит через что-то вроде "именованного файлового интерфейса", тогда ваше приложение может оставаться 32-битным. Если вы попытаетесь сделать что-то вроде разделяемой памяти ("Да! Общая память доступна из пользовательского режима с драйвером?!?"), То вам придется создать приложение как 64-битное.

Ответ 2

Помимо формы @Billy отлично писать, если вы действительно чувствуете необходимость использовать встроенную 64-битную сборку, тогда вы можете использовать внешний ассемблер, такой как MASM, чтобы сделать это, см. это. (его также можно ускорить с помощью сценариев предварительной сборки).

Ответ 3

Intel C Compiler 15 имеет встроенную возможность на 64-битной тоже. И вы можете интегрировать IC в Visual Studio в качестве набора инструментов: тогда у вас будет VС++ 64bit с встроенной сборкой. Один улов, хотя и дорогой приветствия

Ответ 4

Несмотря на это, MinGW также имеет 64-битный встроенный язык ассемблера.

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

На самом деле, люди очень часто делают сборку кода, которая выполняется более эффективно, чем компиляторы - или, по крайней мере, это всегда было обычной мудростью, когда я изучал программирование в 70-х и 80-х годах и продолжал так до 2000 года.
В зависимости от времени, проведенного в циклах и количества кода; рукописная подпрограмма сборки может настолько ускорить выполнение подпрограммы, что производительность, потерянная при оптимизации, может быть незначительной или нулевой, как в случае преобразования всей функции в сборку.

Сборка может иметь место в коде, который требует высокой оптимизации, независимо от того, что говорит M $. Вы действительно не будете знать, будет ли сборка ускорять код, пока не попробуете. Все остальное просто понтификаты.

Я предпочитаю подход компиляции кода c++ в ассемблер, а затем оптимизировать его вручную. Это избавляет вас от необходимости писать большую часть этого; и, немного поэкспериментировав, вы сможете использовать лучшие оптимизации компилятора; а затем начать улучшать это. FWIW, мне никогда не нужно было с современной программой; но для приложений, критичных к производительности, я не вижу причин, чтобы не пытаться; и просто используйте его, если он работает. M $ просто ленится.