Главная страница
Top.Mail.Ru    Яндекс.Метрика
Текущий архив: 2010.03.14;
Скачать: CL | DM;

Вниз

Как правильно читать запись в 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]

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

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


 
Игорь Шевченко ©   (2010-01-13 18:21) [36]


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


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


 
Sha ©   (2010-01-13 18:24) [37]

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

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

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

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


 
Anatoly Podgoretsky ©   (2010-01-13 18:38) [38]

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

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


 
Anatoly Podgoretsky ©   (2010-01-13 18:38) [39]

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

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


 
Anatoly Podgoretsky ©   (2010-01-13 18:40) [40]

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

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



Страницы: 1 2 вся ветка

Текущий архив: 2010.03.14;
Скачать: CL | DM;

Наверх




Память: 0.57 MB
Время: 0.022 c
15-1261949422
Юрий
2009-12-28 00:30
2010.03.14
С днем рождения ! 28 декабря 2009 понедельник


2-1263064919
Zloy
2010-01-09 22:21
2010.03.14
Операции с датами


2-1263287295
Mery
2010-01-12 12:08
2010.03.14
Сложность в построении запроса


15-1261953438
Делфиец
2009-12-28 01:37
2010.03.14
Хочу давно "О чем не пишут в книгах по Delphi" почитать


15-1261776622
Юрий
2009-12-26 00:30
2010.03.14
С днем рождения ! 26 декабря 2009 суббота