Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Начинающим";
Текущий архив: 2010.03.14;
Скачать: [xml.tar.bz2];

Вниз

Как правильно читать запись в 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;
Скачать: [xml.tar.bz2];

Наверх





Память: 0.55 MB
Время: 0.011 c
4-1229881658
Пётр
2008-12-21 20:47
2010.03.14
ID процесса по имени exe-шника


6-1214468171
uzer32.dll
2008-06-26 12:16
2010.03.14
Upnp port-mapping


15-1261783981
Kerk
2009-12-26 02:33
2010.03.14
Вавилон 5


15-1260999367
Германн
2009-12-17 00:36
2010.03.14
"Линия задержки"


2-1263309374
Евгений Р.
2010-01-12 18:16
2010.03.14
Работа с tAdoQuery





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский