Ассемблерные вставки и переносимость кода

← →
KSergey © (2012-06-14 10:00) [0]

1. С интересом прочитал бы размышления Розыча и не только относительно переносимости кода с ассемблерными вставками.

2. С интересом прочитал бы размышления участников форума относительно преимуществ типизированных указателей над нетипизированными.

← →
oxffff © (2012-06-14 10:14) [1]

> KSergey © (14.06.12 10:00)

В чем вопрос по 2?

← →
Rouse_ © (2012-06-14 10:15) [2]

А в чем проблема с переносимостью? :)
Если требуется жесткая привязка к асму (ну например потому что некоторые асм инструкции не вызываются напрямую как-то sysenter) то пишутся два аналога, помещающиеся под директивы компилятора. EAX меняем на RAX и вся не долга, или ты думаешь там все мудренее, чем кажется? :)
Другое дело если имеем конкретный 32 битный проект, который никто не собирается переводить на 64 бита, то проблема с переносимостью вообще банально высосана из пальца :)

← →
Давайте будем жрать! (2012-06-14 10:15) [3]

> преимуществ типизированных указателей над нетипизированными
Вообще-то в первоначальной ветке вопрос ставился иначе.

← →
Ega23 © (2012-06-14 10:17) [4]

> преимуществ типизированных указателей над нетипизированными.

procedure TForm44.Button1Click(Sender: TObject); var p1: PByte; p2: PWord; p3: PInteger; begin p1 := nil; p2 := nil; p3 := nil; Inc(p1); Inc(p2); Inc(p3); ShowMessage(IntToStr(Integer(p1)) + " " + IntToStr(Integer(p2)) + " " + IntToStr(Integer(p3))); end;

← →
Давайте будем жрать! (2012-06-14 10:18) [5]

> Ega23 © (14.06.12 10:17) [4]
Результат от директив компилятора зависит начиная (кажется) с XE.

← →
Ega23 © (2012-06-14 10:22) [6]

> Результат от директив компилятора зависит начиная (кажется) с XE.

У меня нет ХЕ, ничего по этому поводу сказать не могу.

← →
KSergey © (2012-06-14 10:27) [7]

> Ega23 © (14.06.12 10:17) [4]

Это отличие, вернее, это допустимые операции.
С нетипизироваными указателями операции инкремента/декремента (ну и т.п.) просто неприменимы.
Как можно просто наличие свойства называть преимуществом?

То, что соль соленая - это ее преимущество перед сахаром? так получается.

← →
KSergey © (2012-06-14 10:28) [8]

> Давайте будем жрать! (14.06.12 10:18) [5]
> Результат от директив компилятора зависит начиная (кажется) с XE.

Конкретный результат (в цифрах) не важен сейчас.

← →
KSergey © (2012-06-14 10:29) [9]

> Давайте будем жрать! (14.06.12 10:15) [3]
> Вообще-то в первоначальной ветке вопрос ставился иначе.

Считаете, это принципиально?

← →
KSergey © (2012-06-14 10:30) [10]

> oxffff © (14.06.12 10:14) [1]
> В чем вопрос по 2?

Да кабы я знал.
Вот так он был сформулирован Розычем. (Правда тут подсказывают, что с точностью до наоборот, но я не улавниваю разницы, признаться.)

← →
KSergey © (2012-06-14 10:31) [11]

> Rouse_ © (14.06.12 10:15) [2]
> А в чем проблема с переносимостью? :)
> Если требуется жесткая привязка к асму (ну например потому
> что некоторые асм инструкции не вызываются напрямую как-
> то sysenter) то пишутся два аналога, помещающиеся под директивы
> компилятора. EAX меняем на RAX и вся не долга,

Это вот называется переносимость, я правильно понял?

← →
Rouse_ © (2012-06-14 10:32) [12]

> Это отличие, вернее, это допустимые операции.

Это все что ты видишь ?:)

> С нетипизироваными указателями операции инкремента/декремента
> (ну и т.п.) просто неприменимы.

Да ну?
P: Pointer; begin P := PAnsiChar(P) + 100;

← →
Rouse_ © (2012-06-14 10:34) [13]

> Это вот называется переносимость, я правильно понял?

Это поддержка 64 битных компиляторов.

← →
KSergey © (2012-06-14 10:38) [14]

> Rouse_ © (14.06.12 10:32) [12]

Я правильно понимаю, что + 100 применено к нетипизированному указателю?
Розыч, зачем ты пытаешься обмануть?

← →
Rouse_ © (2012-06-14 10:39) [15]

> Я правильно понимаю, что + 100 применено к нетипизированному
> указателю?

Я же даже тип указателя привел :)

← →
KSergey © (2012-06-14 10:40) [16]

> Rouse_ © (14.06.12 10:34) [13]
> > Это вот называется переносимость, я правильно понял?
> Это поддержка 64 битных компиляторов.

Т.е. переписывание кода (а его придется внимательно переписать, т.к., очевидно, реальный код не ограничивается одной операцией сложения 2-х регистров) - это и называется "переносимость"?

Ну тогда речь о различном толковании терминов.

Это, кстати, одна из проблем собеседований бывает. Впрочем, любых так сказать "коммуникаций".

← →
Давайте будем жрать! (2012-06-14 10:42) [17]

> Считаете, это принципиально?
Ну, "там" было что-то вроде "преимущества т.у. над н.т.у и наоборот", а в данной ветке получается, что преимущества нетипизированных над типизированными не обсуждаются — не то ввиду очевидности, не то ввиду отсутствия... По-моему, это довольно сильно меняет вопрос.

← →
KSergey © (2012-06-14 10:42) [18]

> Rouse_ © (14.06.12 10:39) [15]
> Я же даже тип указателя привел

...к типу PAnsiChar

Розыч, я не понимаю зачем обманывать и выкручиваться?

Впрочем, пример про сложение на асме - это уже показательно было очень относительно, в частности, стиля собеседования в вашей компании. Да еще называние это "переносимым" кодом.

← →
Rouse_ © (2012-06-14 10:44) [19]

>
> Т.е. переписывание кода (а его придется внимательно переписать,
> т.к., очевидно, реальный код не ограничивается одной операцией
> сложения 2-х регистров) - это и называется "переносимость"?
>

Нет ты видимо не допонял. В рамках переносимости, код с асм вставками будет скомпилирован на любой дельфи начиная от двойки до хе2(в 32 битах) и FP. Тут проблем не будет. Если требуется поддержка другой разрядности, код естетсвенно должен дописыватся, по примеру того как это сделано в system.pas от этого никуда не уйти, а что ты хотел, тут ничего универсального но оптимизированного не придумать.

← →
KSergey © (2012-06-14 10:44) [20]

> Давайте будем жрать! (14.06.12 10:42) [17]
> Ну, "там" было что-то вроде "преимущества т.у. над н.т.
> у и наоборот", а в данной ветке получается, что преимущества
> нетипизированных над типизированными не обсуждаются

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

← →
Rouse_ © (2012-06-14 10:46) [21]

> ...к типу PAnsiChar
>
> Розыч, я не понимаю зачем обманывать и выкручиваться?

Кто выкручивается? :) Ты сказал что к типизированным операция декремента не применяется - я показал что это не так :) То что инкремент был сделан через приедение,это значит я выкручиваюсь? Ты слишком большого мнения о бо мне :) Тем более данный пример можно написать и по другому, P := Pointer(DWORD(P) + 100) сути этого не поменяет. А вот то что ты до сих пор не сказал одно из явных достоинств типизированных указателей, меня мягко говоря смущает :)

По поводу асма не понял - что там и чего тебе показывает? Разжуй

← →
KSergey © (2012-06-14 10:47) [22]

> Rouse_ © (14.06.12 10:44) [19]

То, что код скомпилируется - это нифига не переносимость. Не мне тебе рассказывать.
"Плавали, заем".

Так что, надеюсь, настаивать на переносимости кода с асм. вставками - надеюсь настаивать ты не будешь больше.

← →
KSergey © (2012-06-14 10:47) [23]

> Rouse_ © (14.06.12 10:46) [21]
> Кто выкручивается? :) Ты сказал что к типизированным операция
> декремента не применяется - я показал что это не так :)

Ты как раз показал, что это - именно так.

← →
Rouse_ © (2012-06-14 10:52) [24]

> Так что, надеюсь, настаивать на переносимости кода с асм.
> вставками - надеюсь настаивать ты не будешь больше.

Что значит не буду? :) Ты кажется не улавливаешь мою специфику. Я в той ветке четко обозначил позицию, есть проект - под него пишется код. Есть блоки асм кода (очень много). Данный проект пережил миграцию с шестой дельфи по 2009-ую без правок асма. Ты же говоришь за некую универсальный код, который портируется куда угодно. Так вот это нам мало того что не нужно, так еще и экономически не выгодно, стало быть с какого перепуга я должен отказываться. Я же речь вел о приеме к нам на работу, где все я сно и понятно а не в некое непонятное сообщество любителей портируемого кода? :)

← →
Rouse_ © (2012-06-14 10:55) [25]

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

← →
KSergey © (2012-06-14 11:18) [26]

> Rouse_ © (14.06.12 10:52) [24]
> Данный проект пережил миграцию с шестой дельфи по 2009-ую без правок асма.

Т.е. "переносимый код" - это переносимый между версиями дельфи, причем снизу-вверх?!!

Н-да...

Тогда, безусловно, переносимый.
Но с терминологией - надо как-то поаккуратнее что-ли, опять же сразу уточнять, "что вы имеете ввиду", на собеседованиях в том числе. Ибо толкование у вас какое-то довольно нетрадиционное-узкоспецифическое.

← →
KSergey © (2012-06-14 11:18) [27]

Так что там с преимуществами?

← →
oxffff © (2012-06-14 11:23) [28]

> Rouse_ © (14.06.12 10:32) [12]
>
> > Это отличие, вернее, это допустимые операции.
>
> Это все что ты видишь ?:)
>
>
> > С нетипизироваными указателями операции инкремента/декремента
>
> > (ну и т.п.) просто неприменимы.
>
> Да ну?
> P: Pointer;
> begin
> P := PAnsiChar(P) + 100;

Саша, не лукавь. Операция производится над типизированным указателем.

> Т.е. "переносимый код" - это переносимый между версиями
> дельфи, причем снизу-вверх?!!

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

> Саша, не лукавь. Операция производится над типизированным
> указателем.

Ну хорошо я там пример привел второй, без типизированного указателя.

> Так что там с преимуществами?

Ну так это ты мне и скажи.

> Rouse_ (14.06.2012 11:33:29) [29]

Там тоже приведение, но уже к целому, а народ хочет без приведения

> а народ хочет без приведения

Когда народ утверждал что инкрементить/декрементить нельзя он ничего не говорил о приведении :)

> Ну хорошо я там пример привел второй, без типизированного
> указателя.

P := Pointer(DWORD(P) + 100)?

Где здесь применяется оператор + к типу pointer?

> Где здесь применяется оператор + к типу pointer?

Здесь производится инкремент пойнтера через приведение, я разве где-то говорил что сам пойнтер можно инкрементировать?

> Здесь производится инкремент пойнтера через приведение,

Здесь приводится приведение к unsigned int, который увеличивается на 100, далее результат приводится к pointer. Это разные вещи.

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

В GC куче такие операции запрещены.

> oxffff © (14.06.12 12:04) [34]
> В Rouse_ © (14.06.12 10:32) [12].

А где я тут сказал? Процитируй.

Если бы я захотел решить инкремент самого пойнтера, то мне пришлось бы обойти ограничение накладываемое компилером, ну что-то вроде:

function IncPointer(Value: Pointer): Pointer; overload; asm inc eax end; function IncPointer(Value: Pointer; Size: Integer): Pointer; overload; asm add eax, edx end;

> Здесь приводится приведение к unsigned int, который увеличивается
> на 100, далее результат приводится к pointer.

Не Серег, там производится именно инкремент нетипизированного указателя, пойнтера :) Т.е. решается вполне конкретная задача :) Все остальное риторика...

> Rouse_ © (14.06.12 12:09) [36]
>
> > oxffff © (14.06.12 12:04) [34]
> > В Rouse_ © (14.06.12 10:32) [12].
>
> А где я тут сказал? Процитируй.

Да ну, Саша.
Но тем не менее, понимаю тебя, поскольку ты человек который смотрит сквозь абстракции, но все же [35].

> Rouse_ © (14.06.12 12:11) [37]
>
> > Здесь приводится приведение к unsigned int, который увеличивается
>
> > на 100, далее результат приводится к pointer.
>
> Не Серег, там производится именно инкремент нетипизированного
> указателя, пойнтера :) Т.е. решается вполне конкретная задача
> :) Все остальное риторика...

Саш, предлагаю на MSIL написать тоже самое.

> Саш, предлагаю на MSIL написать тоже самое.

С условием того, что код должен остаться safe.

Ассемблерные вставки и переносимость кода Найти похожие ветки