Как правильно читать запись в record ассемблерной функции?

← →
yantux © (2010-01-13 15:34) [0]

type
mytype = record
a : integer; (* внутри ассемблерной функции это поле читается и пишется без проблем *)
b : array of array of extended; (* как читать и как писать в это поле внутри ассемлерной функции? *)
end;

procedure test1(var f : mytype) ; assembler;
asm
f.b[0,0];(* как правильно прочитать и правильно записать в это поле для кода с коммандами fpu? *)
end;

var
t : mytype;
begin
setlength(t,20,20);
test1(t);
end;

← →
Сергей М. © (2010-01-13 15:55) [1]

Ты вот скажи - оно тебе зачеми приспичило ?)
Какой бонус ты хочешь получить, обращаясь из асм- , а не из Паскаль-кода ?

← →
Игорь Шевченко © (2010-01-13 15:57) [2]

> b : array of array of extended; (* как читать и как писать
> в это поле внутри ассемлерной функции? *)

а что, в system.pas не написана работа с динамическими массивами на ассемблере ?

← →
Сергей М. © (2010-01-13 15:58) [3]

> с коммандами fpu

Ты считаешь, что дельфийский компилятор напрочь игнорирует FPU, и поэтому решил писать асм-ф-цию ?

← →
Sha © (2010-01-13 16:03) [4]

Напиши на паскале все, что тебе надо,
и посмотри в окне CPU, как тебя понял компилятор.

← →
yantux © (2010-01-13 16:06) [5]

>Ты вот скажи - оно тебе зачеми приспичило ?)
>Какой бонус ты хочешь получить, обращаясь из асм- , а не из Паскаль-кода ?

надеюсь повысить скорость перебора двумерного массива

← →
Сергей М. © (2010-01-13 16:12) [6]

> надеюсь повысить скорость перебора двумерного массива

Да не повысишь ты его при нулевых знаниях)
И при ненуливых ощутимо тоже не повысишь.
К тому же как связан FPU с "перебором", по-твоему ? По-моему никак)

← →
yantux © (2010-01-13 16:31) [7]

> К тому же как связан FPU с "перебором", по-твоему ? По-моему никак)

потому что во время перебора надо выполнять матоперации

← →
yantux © (2010-01-13 16:32) [8]

> Напиши на паскале все, что тебе надо,
> и посмотри в окне CPU, как тебя понял компилятор.

вижу команду wait - надеюсь компилятор добавляет её не случайно?

← →
Сергей М. © (2010-01-13 16:44) [9]

> во время перебора надо выполнять матоперации

Ну и выполняй их себе на здоровье над ОДНИМ эл-том массива, переданным в твою asm-функцию параметром)
Зачем там цикл-то нужен ?
Цикл обращения чтения/записи эл-тов массива пусть останется в вызывающей Паскаль- п/программе - для этого никакой FPU не нужен.
А оптимизированную FPU-обработку extended-параметра выноси в асм-функцию

> wait - надеюсь компилятор добавляет её не случайно?

Конечно не случайно)
Компилятор же не знает, какой CPU будет исполнять этот код..
Это запросто может быть и комплект из 386/387, в котором без WAIT, в отличие от современных CPU, не обойтись.

← →
Сергей М. © (2010-01-13 16:48) [10]

К тогму же, если не ошибаюсь, в D2005 уже поддерживалась директива inline, так что накл.затраты на вызов асм-подпрограммы вообще отсутствуют, и нет никакого резона передавать ей весь массив для обработки

← →
Anatoly Podgoretsky © (2010-01-13 16:55) [11]

> Сергей М. (13.01.2010 15:58:03) [3]

Вые, то есть показать насколько он продвинутый.

← →
Anatoly Podgoretsky © (2010-01-13 16:56) [12]

> yantux (13.01.2010 16:32:08) [8]

Компилятор ничего случайно не добавляет, это же не ГСЧ

← →
Anatoly Podgoretsky © (2010-01-13 17:05) [13]

> Сергей М. (13.01.2010 16:48:10) [10]

Накладные затраты на асм-подпрограммы и паскаль подпрограммы абсолютно одинаковы, и определяются только соглашением о вызове.

← →
Сергей М. © (2010-01-13 17:09) [14]

> Anatoly Podgoretsky © (13.01.10 17:05) [13]

В любом случае рассуждать о реальной необходимости асм-реализации какой-то части алгоритма, согласись, можно только при внятной и подробной постановке задачи. Каковая у автора, по всей вероятности, напрочь отсутствует)

← →
Anatoly Podgoretsky © (2010-01-13 17:18) [15]

> Сергей М. (13.01.2010 17:09:14) [14]

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

← →
yantux © (2010-01-13 17:41) [16]

> Конечно не случайно)
> Компилятор же не знает, какой CPU будет исполнять этот код..
> Это запросто может быть и комплект из 386/387, в котором без WAIT, в > > отличие от современных CPU, не обойтись.

Я не думаю, что программа может быть запущена под win95, а ХР скорее всего даже встать не захочет на 386/387. Скорее всего тянется из прошлых компиляторов.

Но я так понимаю, что она не вносит существенных тормозов?

← →
Sha © (2010-01-13 17:45) [17]

Что мешает проверить? )

← →
yantux © (2010-01-13 17:46) [18]

> К тогму же, если не ошибаюсь, в D2005 уже поддерживалась директива
> inline, так что накл.затраты на вызов асм-подпрограммы вообще
> отсутствуют, и нет никакого резона передавать ей весь массив для
> обработки

Я не собираюсь экономить время на вызовах. Меня больше беспокоит насколько быстро/медленно происходит процесс перебора элементов матрицы. И можно ли этот процесс убыстрить за счёт ассемлера. Поскольку элементы матрицы (двумерный массив) необходимо обсчитывать, встаёт вопрос использования fpu.

← →
yantux © (2010-01-13 17:49) [19]

> Что мешает проверить? )

Как её убрать из кода? В опциях флажка нет, который бы обеспечивал/снимал "совместимость" с 386/387

← →
Sha © (2010-01-13 17:49) [20]

Свой написать без wait?

← →
Игорь Шевченко © (2010-01-13 17:50) [21]

не парься

← →
yantux © (2010-01-13 17:52) [22]

> Ну и выполняй их себе на здоровье над ОДНИМ эл-том массива,
> переданным в твою asm-функцию параметром)
> Зачем там цикл-то нужен ?
> Цикл обращения чтения/записи эл-тов массива пусть останется в
> вызывающей Паскаль- п/программе - для этого никакой FPU не нужен.
> А оптимизированную FPU-обработку extended-параметра выноси в асм-
> функцию

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

← →
yantux © (2010-01-13 17:55) [23]

> Свой написать без wait?

неохота мне переписывать столько кода не будучи уверенным в результате

> не парься

собственно к этому и идёт, потому что после просмотра ассемблерного кода ctrl-alt-c возниклоно понимание, что явно лишних и тормозящего кода я не обнаружил, а в академических целях всё же хотелось бы понять, как в асемблерном коде прочитать запись типа extended для работы с командами fpu

← →
yantux © (2010-01-13 17:58) [24]

> Компилятор ничего случайно не добавляет, это же не ГСЧ

всё же wait он добавляет зря, потому что я уверен, что исходник не запуститьня на 386/387 , потому что туда даже ХР не встанет, хотя это мало что видимо меняет, но всё же хотелось бы услышать однозначный ответ, что wait не вносит существенных тормозов

← →
Sha © (2010-01-13 17:58) [25]

> неохота мне переписывать столько кода не будучи уверенным в результате

почему вообще надо что-то переписывать? для этого существует эксперимент.

← →
yantux © (2010-01-13 18:00) [26]

> Автор наверно где то слышал, что АСМ это быстро и круто, но в результате их поделки работают медленнее паскалевского кода, который конечно можно немного ускорить.

Ни чего и ни где я не слышал. Просто надо использовать железо на максимум. Мне же многое не очевидно в отличии от вас.

← →
yantux © (2010-01-13 18:03) [27]

> Что мешает проверить? )

Наличие/отсутствие тормозов со стороны wait можно проверить только при работе с записями двумерного массивами внутри асемблерного кода. А я не знаю, как это написать, собсвенно из-за чего и открыл топик.

← →
Sha © (2010-01-13 18:03) [28]

> однозначный ответ, что wait не вносит существенных тормозов

спросить у intel?

> Просто надо использовать железо на максимум

для этого надо знать слабое место в коде, а не гадать

← →
Sha © (2010-01-13 18:07) [29]

> записями двумерного массивами внутри асемблерного кода.
> А я не знаю, как это написать

Ты же в окно CPU заглядывал

← →
yantux © (2010-01-13 18:07) [30]

> для этого надо знать слабое место в коде, а не гадать

Cлабое место - перебор записей двумерного массива.

Кроме того обидно, что среди "наворотов" mmx, sse, sse3 3dnow! нет нормальных функций для работы с большими матрицами элементов типа extended (родной для fpu).

← →
Игорь Шевченко © (2010-01-13 18:09) [31]

> как в асемблерном коде прочитать запись типа extended для
> работы с командами fpu

fld ?

← →
yantux © (2010-01-13 18:09) [32]

> Ты же в окно CPU заглядывал

предлагаете накопипастить? боюсь наделать ошибок, ведь это жен не сплошной кусок кода, хотя надо подумать, может оно и так надо в тестовом примере сделать...

← →
Sha © (2010-01-13 18:11) [33]

> Cлабое место - перебор записей двумерного массива

Как узнал?

Что есть перебор? Это переход к следующему элементу?

← →
yantux © (2010-01-13 18:11) [34]

> fld ?

type
mytype = record
a : integer; (* внутри ассемблерной функции это поле читается и пишется без проблем *)
b : array of array of extended; (* как читать и как писать в это поле внутри ассемлерной функции? *)
end;

procedure test1(var f : mytype) ; assembler;
asm
f.b[0,0];(* как правильно прочитать и правильно записать в это поле для кода с коммандами fpu? *)

fld ? (* как мне здесь добраться до элементов массива ? *)

end;

var
t : mytype;
begin
setlength(t,20,20);
test1(t);
end;

← →
yantux © (2010-01-13 18:15) [35]

> Как узнал?
несколько десятков матриц, матрица большая, размер строки и столбца на несколько сотен элементов

> Что есть перебор? Это переход к следующему элементу?
да, при чём расчитывается по формуле, в которой используются большая часть элементов матрицы

> как мне здесь добраться до элементов массива

Прочитав пост [2]

>> Как узнал?
> несколько десятков матриц, матрица большая,
> размер строки и столбца на несколько сотен элементов

Я тоже иногда кое-что рассчитываю. Иногда много. Иногда тысячи элементов. Скорость устраивает.

>> Что есть перебор? Это переход к следующему элементу?
> да

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

> yantux (13.01.2010 17:58:24) [24]

Читай документацию по процессору, с сайта Интел.
Статью на моем сайте ты все равно игнорируешь.

> yantux (13.01.2010 18:00:26) [26]

Ты прочитал документацию Интела по оптимизации? Есть и такой том.

> yantux (13.01.2010 18:03:27) [27]

Наличие/отсутствие тормозов со стороны wait можно проверить на любом коде.
Достаточно написать две версии с wait и без и профилировать этот код любым доступным методом.

> yantux (13.01.2010 18:07:30) [30]

Какие именно команды/последовательности команд.

> yantux (13.01.2010 18:11:34) [34]

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

> Читай документацию по процессору, с сайта Интел.
> Статью на моем сайте ты все равно игнорируешь.

С удовольствием прочитал бы вашы статьи, но этой ветке форума нет ни одной ссылки на сайты в инете.

> Ты прочитал документацию Интела по оптимизации? Есть и такой том.

Я смотрел в инете в основном обзорные статьи людей, которые занимаются оптимизацией кода и на примерах разбирают возможности по mmx, sse, sse2. В одной статье было сказано, что достаточно просто нормально написать алогритм, а mmx, sse дают не очень ощутимый прирост производительности.

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

[23]

> mmx, sse дают не очень ощутимый прирост производительности

Ты считаешь, что эти расширения были придуманы и реализованы Интелом от нечего делать ?)

> Сергей М. (14.01.2010 10:07:47) [47]

А почему бы и нет? Чего ради маркетинга не сделаешь. Главное повышение производительности будет подтверждено ТЕСТАМИ

> Ты считаешь, что эти расширения были придуманы и реализованы Интелом от нечего делать ?)

Не знаю, со вечкой не стоял, но для больших матриц это не катит (mmx ограничение размера матрицы 8х8) и тип extended (родной для fpu) я так понимаю не поддерживается (у mmx целочисленный тип данных).

Ну и что ?
Перед MMX и задачи несколько иные стоят, нежели тебя интересующие..
Но это же вовсе не говорит о том, что MMX - это 5-е колесо у телеги)

> Ну и что ?
> Перед MMX и задачи несколько иные стоят, нежели тебя интересующие..
> Но это же вовсе не говорит о том, что MMX - это 5-е колесо у телеги)

Я ни чего плохого про mmx не сказал. Возможно эта технология очень востребована.

Как правильно читать запись в record ассемблерной функции? Найти похожие ветки