Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

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

Страницы: < 1 2 3 >
yantux © (2010-01-13 15:34:00)
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 18:09:00) [21]

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

fld ?

yantux (2010-01-13 18:07:00) [22]
> для этого надо знать слабое место в коде, а не гадать

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

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

Sha (2010-01-13 18:07:00) [23]
> записями двумерного массивами внутри асемблерного кода.
> А я не знаю, как это написать

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

Sha (2010-01-13 18:03:00) [24]
> однозначный ответ, что wait не вносит существенных тормозов

спросить у intel?

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

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

yantux (2010-01-13 18:03:00) [25]
> Что мешает проверить? )

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

yantux (2010-01-13 18:00:00) [26]
> Автор наверно где то слышал, что АСМ это быстро и круто, но в результате их поделки работают медленнее паскалевского кода, который конечно можно немного ускорить.

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

Sha (2010-01-13 17:58:00) [27]
> неохота мне переписывать столько кода не будучи уверенным в результате

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

yantux (2010-01-13 17:58:00) [28]
> Компилятор ничего случайно не добавляет, это же не ГСЧ

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

yantux (2010-01-13 17:55:00) [29]
> Свой написать без wait?

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

> не парься

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

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

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

Игорь Шевченко (2010-01-13 17:50:00) [31]
не парься

Sha (2010-01-13 17:49:00) [32]
Свой написать без wait?

yantux (2010-01-13 17:49:00) [33]
> Что мешает проверить? )

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

yantux (2010-01-13 17:46:00) [34]
> К тогму же, если не ошибаюсь, в D2005 уже поддерживалась директива
> inline, так что накл.затраты на вызов асм-подпрограммы вообще
> отсутствуют, и нет никакого резона передавать ей весь массив для
> обработки

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

Sha (2010-01-13 17:45:00) [35]
Что мешает проверить? )

yantux (2010-01-13 17:41:00) [36]
> Конечно не случайно)
> Компилятор же не знает, какой CPU будет исполнять этот код..
> Это запросто может быть и комплект из 386/387, в котором без WAIT, в > > отличие от современных CPU, не обойтись.

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

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

Anatoly Podgoretsky (2010-01-13 17:18:00) [37]
> Сергей М. (13.01.2010 17:09:14) [14]

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

Сергей М. (2010-01-13 17:09:00) [38]

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

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

Anatoly Podgoretsky (2010-01-13 17:05:00) [39]
> Сергей М. (13.01.2010 16:48:10) [10]

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

Anatoly Podgoretsky (2010-01-13 16:56:00) [40]
> yantux (13.01.2010 16:32:08) [8]

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

Страницы: < 1 2 3 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »