Здравствуйте Речка, Вы писали:

Р>Здравствуйте VuDZ и Alex Fedotov.
Р>Очень интересно почитать вашу переписку не являясь знатоком asm'a.

Р>А ведь наверное первое, что делает ваша программа,
Р>использующая asm — это определение типа процессора?
Р>С этого и все начинающие программеры на asm'e начинают.

Р>Подскажите пожалуйста, как точно узнать тип процессора программно?

ну на RTFM не будем-с посылать...
вот как я делал на наличие MMX & SSE проверки:

_IsMMX = false;
    _IsSSE = false;

    _asm
    {
        pusha;
        mov eax, 1;
        cpuid;
        bt edx, 32;
        jnc near _exitSSE;
        mov _IsSSE, 1;
_exitSSE:
        bt edx, 23;
        jnc near _exitMMX;
        mov _IsMMX, 1;
_exitMMX:
        popa;
    };

вот как у AMD:

 mov     eax,0           // function 0 = manufacturer string
            CPUID

            // These tests could probably just check the 'ebx' part of the string,
            // but the entire string is checked for completeness.  Plus, this function
            // should not be used in time-critical code, because the CPUID instruction
            // serializes the processor. (That is, it flushes out the instruction pipeline.)

            // Test for 'AuthenticAMD'
            cmp     ebx,'htuA'
            jne     short not_amd
            cmp     edx,'itne'
            jne     short not_amd
            cmp     ecx,'DMAc'
            jne     short not_amd
            mov     eax,MFG_AMD
            jmp     short next_test

так что ищи описание CPUID

Здравствуйте VuDZ, Вы писали:

VDZ>Здравствуйте VuDZ, Вы писали:

VDZ>Спасибо всем отвечавшим :)
VDZ>особенно Alex Fedotov'у
VDZ>если кого заинтерисовало то. о чём тут вели разговор — тут лежит библиотека с некоторыми стандартнми функциями, реализованные через MMX...
VDZ>о реализованных функциях написано тут... Все пожелания на счёт добавления чего-ньть мыльте мне

Я конечно дико извеняюсь, но на VC6.0
команда prefetcht0 — не понимается, компилятор говорит что ошибка
может потому что у меня P-II?

Спасибо

Здравствуйте Gambler, Вы писали:

G>Я конечно дико извеняюсь, но на VC6.0
G>команда prefetcht0 — не понимается, компилятор говорит что ошибка
G> может потому что у меня P-II?

Чтобы в inline assembler VC6.0 можно было использовать команды MMX и SSE, нужно скачать Visual C++ Processor Pack: http://msdn.microsoft.com/vstudio/downloads/ppack/download.asp (чуть больше 1 MB, но требует установленного Service Pack 4 или Service Pack 5).

Но работать на PII команда prefetcht0 не будет все равно: эта инструкция появилась только в PIII в составе SSE.

Здравствуйте Gambler, Вы писали:

G>Я конечно дико извеняюсь, но на VC6.0
G>команда prefetcht0 — не понимается, компилятор говорит что ошибка
G> может потому что у меня P-II?

Для компиляции нужен processor pack
От процессора это не зависит...

успехов

Здравствуйте Alex Fedotov, Вы писали:

AF>Но работать на PII команда prefetcht0 не будет все равно: эта инструкция появилась только в PIII в составе SSE.
На счёт prefetcht0 — я зпускал пример с этой командой на 600Cel — всё работает... movntq — падает, а прекеширование работает... Честно говоря, с легка запутался — где MMX, MMX2, SSE MMX... — вся дока очень противоречива, а по интелу походить — руки не доходят

Жаль пока нет (у меня в компе) AtlnonXP — SSE вещь очень классная, по крайней мере чать команд весьма полезны — с постфиксом _q...

тут лежит реализация копирования памяти от АМД... Сделано просто супер...
Мда... а я то думал, что знаю асм

AF>В свое время я столкнулся с ситуацией, когда нужно было делать примерно следующее.

AF>WORD buffer1[N]; // DWORD-aligned
AF>WORD buffer2[N]; // DWORD-aligned as well

AF>memcpy(buffer2 + 1, buffer1, (N — 1) * sizeof(WORD));

AF>Короче, you got the idea. Здесь получалось, что либо чтение будет DWORD-aligned, либо запись — данные так устроены. memcpy выбирала запись и проигрывала — когда я сделал свою версию, которая делала DWORD-aligned чтение, а писала как получится, она оказалась в среднем на 30% быстрее (PIII).

утилита от intel — показывает влияние выравнивания даных/наличие их в кэше

А если данные не выравнены
Имеет смысл использовать асм?

Здравствуйте, VuDZ, Вы писали:

VDZ>сейчвс этот код на 36% быстрее. чем memcpy() на гиговом Атлоне, но может можно его ещё ускорить ? А то , только мне по голове

VDZ>Thanx for your attantion

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

давно скачивал, должны быть...

помоему тут:

http://cdrom.amd.com/devconn/library.zip

Здравствуйте, VuDZ, Вы писали:

VDZ>Subj такой — надо с максимально озможной скоростью копировать данные из одного куска памяти в другой. Подошёл бы
VDZ>Thanx for your attantion

во, вспопмнил урл:

http://cdrom.amd.com/devconn/memcpy_amd.zip

там оптимайзенный memcpy...

А как насчёт использования для копирования память-память контроллера DMA?
Реализация будет посложнее и скорость, наверняка, поменьше
Зато можно ЦПУ в это время чем-нить другим загружать

Здравствуйте, Аноним, Вы писали:

А>А как насчёт использования для копирования память-память контроллера DMA?
А>Реализация будет посложнее и скорость, наверняка, поменьше
Почему поменьше? По-моему как раньше так и сейчас — побольше. Вряд ли у современных DMA контроллеров высокая латентность буферов (скорее всего вообще отсутствует). Разве что они конвееризацию не понимают (тут точно не знаю, но скорее всего понимают). Выигрыш при копировании процессором будет только в том случае, когда часть из копируемых данных у него лежит в кэше (кэшах).

Другой вопрос как организовать грамотный (защищенный) интерфейс этого дела со стороны ОС ...

Здравствуйте, Murr, Вы писали:


M>Почему поменьше? По-моему как раньше так и сейчас — побольше. Вряд ли у современных DMA контроллеров высокая латентность буферов (скорее всего вообще отсутствует). Разве что они конвееризацию не понимают (тут точно не знаю, но скорее всего понимают). Выигрыш при копировании процессором будет только в том случае, когда часть из копируемых данных у него лежит в кэше (кэшах).

M>Другой вопрос как организовать грамотный (защищенный) интерфейс этого дела со стороны ОС ...

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

Здравствуйте, Аноним, Вы писали:

А>Надо, видимо, писать драйвер с соответствующей функциональностью.
Тут две проблемы:
1) несогласованность линейных и физических адресов (фрагментация).
2) некий продвинутый интерфейс блокировки пользовательских страничек в памяти.

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

Здравствуйте, Murr, Вы писали:

M>Тут две проблемы:
M>1) несогласованность линейных и физических адресов (фрагментация).

хех
интересно, а при трансферах размером в страницу выигрыш будет? если да, то и чёрт с ней, с фрагментацией

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

а я всегда думал, что некоторые драйвера делают DMA-пересылки прямо в "пользовательскую" память
и, соответственно, в ОСях такие механизмы блокировок предусмотрены
(повторюсь — я в этих вопросах дилетант, если не сказать хуже )

Здравствуйте, Аноним, Вы писали:

А>хех
А>интересно, а при трансферах размером в страницу выигрыш будет? если да, то и чёрт с ней, с фрагментацией
Ну предположим, что частота системной шины 100 Мгц, процессора — 1000 Мгц.
Предположим, что каждые два такта системной шины, DMA выставляет либо запрос на запись в память, либо запрос на чтение памяти (2 такта — это, конечно, лажа. Но для подсчета порядка должно хватить). Шина данных — 64 бит (8 байт).

Потребуется 4096(байт)/8(байт/такт)*2(такта)=256 тактов шины. Т.е. 2560 тактов свободного процессорного времени (в это время процессор, естественно, не будет иметь доступа к шине — на ней будут проходить циклы слежения, инициированные чипсетом, для поддержки когерентности non-Modified строк кэша и ОЗУ).

А>а я всегда думал, что некоторые драйвера делают DMA-пересылки прямо в "пользовательскую" память
А>и, соответственно, в ОСях такие механизмы блокировок предусмотрены
Ну да, в общем. Нужна примерно такая же схема и для DMA память-память. Блокировка диапазона ввода+блокировка диапазона вывода, DMA запрос, разблокировка.

Я писал:

M>Потребуется 4096(байт)/8(байт/такт)*2(такта)=256 тактов шины. Т.е. 2560 тактов свободного процессорного времени...

Ой как круто посчитал... Аж самому понравилось.
Должно быть 4096(байт)/8(байт/такт)*2(безразм.)=1024 тактов шины. Т.е. 10240 тактов процессорных часов.

Здравствуйте, Murr, Вы писали:

M>Предположим, что каждые два такта системной шины, DMA выставляет либо запрос на запись в память, либо запрос на чтение памяти (2 такта — это, конечно, лажа. Но для подсчета порядка должно хватить). Шина данных — 64 бит (8 байт).

M>Потребуется 4096(байт)/8(байт/такт)*2(такта)=256 тактов шины. Т.е. 2560 тактов свободного процессорного времени (в это время процессор, естественно, не будет иметь доступа к шине — на ней будут проходить циклы слежения, инициированные чипсетом, для поддержки когерентности non-Modified строк кэша и ОЗУ).

Интересно. А где про все эти железячные тонкости почитать можно?

M>Ой как круто посчитал... Аж самому понравилось.

Правая ассоциативность рулит

M>Должно быть 4096(байт)/8(байт/такт)*2(безразм.)=1024 тактов шины. Т.е. 10240 тактов процессорных часов.

Я очень извиняюсь, но что означает эта волшебная цифра для нас, простых смертных?

Сколько аналогичных "попугаев" будет при копировании через регистры, и почему DMA быстрее.

И ещё очень интересно, каково при всём этом влияние кэша. Т.е. выгодно ли кэширование, или нет? И почему?

Здравствуйте, Аноним, Вы писали:

А>Правая ассоциативность рулит
Ага

А>Я очень извиняюсь, но что означает эта волшебная цифра для нас, простых смертных?

Ну по идее это означает, что можно выполнить 10240(+-)10240 ассемблерных инструкций за время копирования

А>Сколько аналогичных "попугаев" будет при копировании через регистры
Если без вытеснения кэша, то столько же. Если с вытеснением кэша (т.е. если начнем засорять кэш), то больше. Если часть данных уже находится в кэше (т.е. не нужно выполнять чтение из памяти), то меньше.

А>И ещё очень интересно, каково при всём этом влияние кэша. Т.е. выгодно ли кэширование, или нет? И почему?
Ну с точки зрения самого копирования (что для DMA, что для процессора, минуя кэш) — нет никакой разницы — что процессор, что DMA контроллер — будут формировать одни и те же шинные циклы: read->write->read->write или burst read->burst write->burst read->burst write. Если есть кэш, то он может как немного помогать (если он тем самым исключает фазу чтения, т.е. содержит копируемые данные), так и мешать (когда копируемые данные при чтении начинают вытеснять уже находящиеся в кэше).

Тонкости зависят от процессора и DMA контроллера. Но, для PC всё примерно так, как я написал (Pentium Manual, 8259A Manual на developer.intel.com).

Я писал:

M>Тонкости зависят от процессора и DMA контроллера. Но, для PC всё примерно так, как я написал (Pentium Manual, 8259A Manual на developer.intel.com).
То бишь 8237A... ( у кого что болит, тот о том и говорит )