Рассылка закрыта
При закрытии подписчики были переданы в рассылку "RFpro.ru: Ассемблер? Это просто! Учимся программировать" на которую и рекомендуем вам подписаться.
Вы можете найти рассылки сходной тематики в Каталоге рассылок.
RusFAQ.ru: программирование на языке Assembler
Информационный Канал Subscribe.Ru |
RusFAQ.ru: программирование на языке Assembler
Выпуск № 564
от 11.06.2003, 11:10
Администратор: Имя: Калашников О.А. URL: Информационный ресурс ICQ: 68951340 Россия, Москва |
О рассылке: Задано вопросов: 3431 Отправлено ответов: 10102 Активность: 294.4 %
|
Список экспертов, ответы которых опубликованы в данном выпуске |
Дмитрий Статус: Опытный Общий рейтинг: 149.6 [Подробней >>] |
Bob Johnson Статус: Профессиональный Общий рейтинг: 151.78 URL: Программирование [Подробней >>] |
baldr Статус: Профессиональный Общий рейтинг: 112.32 URL: Сайт об ОС DOS. Всем, кто любит эту ОС! [Подробней >>] |
Tigran K. Kalaidjian Статус: Опытный Общий рейтинг: 118.32 URL: Методы оптимизации работы ПК [Подробней >>] |
masquer Статус: Профессиональный Общий рейтинг: 138.13 [Подробней >>] |
Hangatyr Статус: Опытный Общий рейтинг: 115.68 [Подробней >>] |
Maverick Статус: Профессиональный Общий рейтинг: 131.42 URL: Эхоконференция по вирмейкингу Телефон: 89039415024 (BeeLine GSM) [Подробней >>] |
_vt Статус: Опытный Общий рейтинг: 120.27 [Подробней >>] |
Краткий перечень вопросов |
Вопрос № 3383. Программирую com-port, использовать dos функции нельзя. Не могу понять почему принимается мусор. Вот... (ответов: 1)
Вопрос № 3384. Прошу прощения за возможный повтор - у меня идут ошибки доставки (полный попандос), поэтому дублирую... (ответов: 1)
Вопрос № 3385. Будьте добры, дать ссылки на электронные книжки по теме "программирование MFC", или может ... (ответов: 1)
Вопрос № 3386. Все привет! Подскажите, алгоритм разрезания прямоугольной платы на прямоугольные части. Ссылки и мыл... (ответов: 4)
Вопрос № 3387. На сервере Windows 2003 не запускается SoftIce v4.05. Можно ли чем то помочь? Спасибо.... (ответов: 4)
Вопрос № 3388. 2Bob Johnson: Позволю себе полностью не согласиться с Broken Sword: > особенно когда прога на асме п... (ответов: 5)
Вопрос № 3389. >VC поместит ее адрес в один из вышеназванных регистров и сделает два раза, например, call ebx. Это ... (ответов: 2)
Вопрос № 3390. Здравствуйте, уважаемые эксперты! Вопрос не по ассемблеру как языку, а по работе отладчика. Я пользу... (ответов: 2)
Вопрос № 3391. Zdravstvuite Tovarish MozgC. // Tut vi pisali pro patch k SoftIce. Ya tut shaz ego kachayu s belaru... (ответов: 1)
Вопрос № 3393. Здраствуйте уважаемые эксперты! Подскажите, пожалуйста, как на ассемблере без использования АПИ функ... (ответов: 7)
Вопросов: 10, ответов: 28
Вопрос № 3383 |
Программирую com-port, использовать dos функции нельзя. Не могу понять почему принимается мусор. Вот листинг:
.model small ;код и данные помещаются в 64к+64к, тип near
.stack 100
.data
serial dw ? ;Addr of com-port
char_r db ? ;recieved char
char_s db ? ;sent char
.code
;-------========Get com-port addr========-------------
get_port proc
xor ax,ax
mov es,ax
mov dx,es:[402h]
mov serial,dx
ret
endp get_port
;--------========Init com-port==========---------------
port_init proc
mov dx, serial ;lcr
add dx, 3 ;
mov al, 80h ;set DLAB
out dx, al
mov ax, 384
mov dx, serial ;low bit
out dx, al ;divider 0ch for 300
mov al, ah ;high bit
inc dx
out dx, al
mov dx, serial ;lcr
add dx, 3 ;
mov al, 00000011b;length 8 bit, clear DLAB
out dx, al ;no parity, break off, 1 stop bit
;for debug
; inc dx ;mcr
; mov al, 00011b ;set loopback&DTR&RTS
; out dx, al
mov dx, serial
add dx, 2
xor ax, ax
out dx, al
ret
endp port_init
;-------------==================--------------------
start:
mov ax, @data ;ds указывает на
mov ds, ax ;.data
cli
call get_port
call port_init
main:
trying:
mov dx, serial ;lsr
add dx, 5 ;
in al, dx
test al, 2 ;data recieved?
jnz recieve
mov ah, 11h ;
int 16h ;считать с клавиатуры
jz trying ;keybuffer empty
mov ah, 0h ;
int 16h
mov char_s, al ;save char
cmp al, 27 ;нажат ESC?
jz exit ;выход по ESC
mov dl, char_s ;output char
mov ah, 2
int 21h
test al, 20h ;transmit ready?
jz trying
mov dx, serial ;
mov al, char_s ;transmit char
out dx, al ;
jmp main
recieve:
in al, dx ;recieve char
mov char_r, al ;
mov dl, char_r
mov ah, 2 ;output it
int 21h ;
jmp main
exit:
sti
mov ah, 4ch
int 21h
end start
Вопрос отправлен: 06.06.2003, 10:54
Отправитель: fallen (tony@omen.ru)
[Следующий вопрос >>] [Список вопросов]
Отвечает Дмитрий
Доброе время суток, fallen!
Мусор принимался по нескольким причинам. За проверку поступления данных отвечает 0 бит регистра состояния линии. И в строке receive: in al, dx в dx находился адрес регистра состояния линии, а не адрес регистра данных. Плюс еще несколько мелких недочетов. В приложении приведен работоспособный пример, принимающий данные от COM-мышки (всвязи с этим я жестко задал базовый адрес порта). Кстати, данный пример не заработал у меня под WinME (там даже тип UART правильно не определился!), только под ДОС. При движении мышкой экран заполняется разными символами, создавая причудливые узоры. Но что-бы все работало у тебя должен быть установлен ДОС-драйвер mouse.com, в противном случае контроллер мышки не активизируется и она останется мертвенькой и не захочет разговаривать с UART твоего компа. В принципе, можно дописать еще кучу команд и получится драйвер мыши, но тебе скорее всего это не нужно. Кстати! Обрати внимание на процедуру port_init. Параметры твоего порта были следующие: 300 бод, 8 бит + стопбит, без четности. Устройство, подключенное к порту должно обеспечить подачу именно такого типа данных, иначе опять получишь кашу. Удачи!
Приложение:
Ответ отправлен: 09.06.2003, 05:39
Отправитель: Дмитрий
Вопрос № 3384 |
Прошу прощения за возможный повтор - у меня идут ошибки доставки (полный попандос), поэтому дублирую.
Спасибо за детальнейший (не могу поставить ударение) ответ (это Бобу Джонсону), переформулируем вопрос . Вопрос в том, какого размера эта структура должна быть на самом деле. Например, в декларациях асемблера winsock.inc (взятые у того же Microsoft) структура описана емкостью 398. В файлах С она также описана емкостью 398, но с "внутренним" выравниванием получается 400. При подключение на С winsock.h получаем 398 и никакого выравнивания, при подключении winsock2.h получаем выравниевание до 400. Причем это выравнивание происходит за счет pshpack4.h Эти файлы специально для этого и созданы и присутствуют (pshpack1.h, pshpack2.h, pshpack4.h, pshpack8.h - соответственно граница выравнивания). Что это за политика с выравниванием и какого на самом деле должна быть вышеупомянутая струтура (в понимании Windows - проверить нельзя, Windows XP ee практически не заполняет (последние поля)).
А подшивать winsock2.y нужно - только там декларированы нужные структуры (например WSAPROTOCOL_INFO)
Вопрос отправлен: 06.06.2003, 14:25
Отправитель: то же
[Следующий вопрос >>] [Список вопросов]
Отвечает Bob Johnson
Добрый день, то же!
Я никогда об этом не задумавался и всегда подключал winsock2.h. Могу сказать так - если тебе вообще не нужно значение последнего поля, то используй 400-байтный вариант. Тогда структура точно не окажется меньше, а значит все будет работать.
Более того, заглянул в MSDN и увидел следующее по поводу этого поля:
lpVendorInfo
Ignored for Windows Sockets version 2 and onward. It is retained for compatibility with Windows Sockets specification 1.1. Applications needing to access vendor-specific configuration information should use getsockopt to retrieve the value of option PVD_CONFIG. The definition of this value (if utilized) is beyond the scope of this specification.
Note An application should ignore the iMaxsockets, iMaxUdpDg, and lpVendorInfo members in WSAData if the value in wVersion after a successful call to WSAStartup is at least 2. This is because the architecture of Windows Sockets has been changed in version 2 to support multiple providers, and WSAData no longer applies to a single vendor's stack. Two new socket options are introduced to supply provider-specific information: SO_MAX_MSG_SIZE (replaces the iMaxUdpDg element) and PVD_CONFIG (allows any other provider-specific configuration to occur).
Ты же используешь версию 2.2, видимо? Так что сделай структуру 400 байт и все.
* EMan1.1: ---===*** Eternal power ***===---
Ответ отправлен: 06.06.2003, 18:47
Отправитель: Bob Johnson
Вопрос № 3385 |
Будьте добры, дать ссылки на электронные книжки по теме "программирование MFC", или может кто-нибудь может выслать на мыло.
Заранее спасибо.
Best regards
alexneta.
P.S.
На С/С++ не ответили, поэтому к вам, сори.
Вопрос отправлен: 06.06.2003, 16:59
Отправитель: alexneta (alexneta@bezeqint.net)
[Следующий вопрос >>] [Список вопросов]
Отвечает baldr
Здравствуйте, alexneta!
www.firststeps.ru на первый месяц хватит, думаю... :)
Ну, и MSDN рулит! www.msdn.microsoft.com
Ответ отправлен: 06.06.2003, 17:20
Отправитель: baldr
Вопрос № 3386 |
Все привет!
Подскажите, алгоритм разрезания прямоугольной платы на прямоугольные части.
Ссылки и мыло приветствуется. Все что у вас есть на эту тему.
P.S.
Сори за офтопик, но, по-моему, это единственный раздел, где можно получить нормальный ответ.
Best regards
alexneta.
Вопрос отправлен: 06.06.2003, 17:14
Отправитель: alexneta (alexneta@bezeqint.net)
[Следующий вопрос >>] [Список вопросов]
Отвечает Bob Johnson
Здравствуйте, alexneta!
> Подскажите, алгоритм разрезания прямоугольной платы на прямоугольные части.
Ну а конкретнее нельзя? Какие части, какое условие и т.д. Под то, что ты написал подходит просто взять более длинную сторону и разделить ее пополам. Плата была прямоугольная? Да. Значит два полученных куска тоже будут прямоугольными. Все, алгоритм готов.
* EMan1.1: ---===*** Eternal power ***===---
Ответ отправлен: 06.06.2003, 18:47
Отправитель: Bob Johnson
Отвечает Tigran K. Kalaidjian
Добрый день, alexneta!
Берете плату, берете пилу и режете =)
Если я правильно понял, то это - что-то, связанное с выкладыванием паркетажей(можно ли разрезать прямоугольник на одинаковые прямоугольники). Если это так, то советую почитать мою статью на эту тему(страница 6):
http://kalaidjian.narod.ru/mozaic.rar
Ответ отправлен: 07.06.2003, 12:15
Отправитель: Tigran K. Kalaidjian
Отвечает masquer
Доброе время суток, alexneta!
Алгоритм Монте-Карло?
Ответ отправлен: 06.06.2003, 17:33
Отправитель: masquer
Отвечает --- Нет данных ---
Добрый день, alexneta!
Берешь прямуоугольную плату, линейку, карандаш.
Расчерчиваешь плату на необходимые прямоугольные части и потом с помощью спец. инструментов разрезаешь.
Ответ отправлен: 06.06.2003, 17:44
Отправитель: --- Нет данных ---
Вопрос № 3387 |
На сервере Windows 2003 не запускается SoftIce v4.05.
Можно ли чем то помочь?
Спасибо.
Вопрос отправлен: 06.06.2003, 18:29
Отправитель: Serg
[Следующий вопрос >>] [Список вопросов]
Отвечает --- Нет данных ---
Здравствуйте, Serg!
Попробуй скачать тот же патч (для SoftIce) что и для WinXp
на моем сайте : http://MozgC.narod.ru
распакуй файлы в windowssystem32drivers и перезагрузи комп.
Ответ отправлен: 06.06.2003, 19:19
Отправитель: --- Нет данных ---
Отвечает Bob Johnson
Приветствую Вас, Serg!
Найти версию SoftIce, которая будет поддерживать win 2003 или установить другую версию windows.
* EMan1.1: ---===*** Eternal power ***===---
Ответ отправлен: 06.06.2003, 19:37
Отправитель: Bob Johnson
Отвечает Hangatyr
Здравствуйте, Serg!
Помочь можно новым Айсом. Ну, или патч попробовать поставить.
Ответ отправлен: 07.06.2003, 05:19
Отправитель: Hangatyr
Отвечает masquer
Приветствую Вас, Serg!
Ставь более новый. Тот что идет с Driver Studio/Suite 2.6 и 2.7 ставится на ура.
Ответ отправлен: 06.06.2003, 18:39
Отправитель: masquer
Вопрос № 3388 |
2Bob Johnson:
Позволю себе полностью не согласиться с Broken Sword:
> особенно когда прога на асме писана и избыточность практически нулевая
На чем ты пишешь программу практически не влияет на ее степень сжатия
вот тут я теперь позволю не согласиться...
от языка программирования, на котором писана прога (а если быть конкретнее - то от компиллятора, которым она компилена) зависит практически ВСЕ что касается избыточности. Естественно, я не имел ввиду данные (если прога на асме содержит 100 Мб нулей данных то ее можно назвать избыточной), или таблицы импорта/экспорта. Имелся ввиду только КОД программы. Например, компилер Дельфи вставляет где ни попадя _try _exept на свое усмотрение, начала всех процедур практически идентичны, также результатом творчества компиллятора нередко становятся "дыры" из нулей на несколько сотен байт (и это прямо в коде!).
Теперь об асме. Тут от компиллятора не зависит НИЧЕГО (фактически ты пишешь в маш. кодах с точки зрения избыточности). Избыточность асмовских прог определяется только стилем написания и зависит от программиста.
Впринципе, если сильно поискать то где-нить в "Теории трансляци" можно найти доказательство того, что компиленный исходник с языка высокго уровня намного избыточнее чем машинный код (читай - асм), хотя это и так ясно интуитивно.
Насчте твоего исходинка - тут ты пишешь что он сжался с 8 Кб до 3Кб. Что ж, возможно. Рискну предположить, что у тебя был избыточный стиль написания - много CALL-ов, одни и те же параметры перед вызовом, возможно применял макросы (?) (признавайся! :).
Вообщем, конечно я может утрирую, но возьми ЛЮБОЙ исходник с hugi.de/compo (побольше, хотя там таких нет), сожми его ЛЮБЫМ алгоритмом сжатия (практически не сожметься), и возьми ту же самую прогу на С (идет в качестве Example к любому compo) - результаты скажут сами за себя
предлагаю другим экспертам также включиться в дискус и высказать свое мнение
Вопрос отправлен: 06.06.2003, 19:16
Отправитель: Broken Sword (brokensword@mail.ru)
[Следующий вопрос >>] [Список вопросов]
Отвечает --- Нет данных ---
Че то из-за моего вопроса щас война начнется =)
Ответ отправлен: 06.06.2003, 19:29
Отправитель: --- Нет данных ---
Отвечает Hangatyr
Доброе время суток, Broken Sword!
По большому счету согласен - энтропия программы написанной на асме (грамотно написанной, конечно) будет больше, чем у программы, созданной компилятором - ведь он преобразует код HLL в машинный, используя некие правила, а в случае с асмом программер сам решает, что писать, и в некоторой степени оптимизирует (даже если не преследует такой цели) написанный им код, но тут многое, как ты сказал, зависит от стиля программирования - и на асме можно писать так, что получится не лучше, чем у компилятора.
Ответ отправлен: 06.06.2003, 19:54
Отправитель: Hangatyr
Отвечает Bob Johnson
Приветствую Вас, Broken Sword!
> от языка программирования, на котором писана прога (а если быть конкретнее - то от компиллятора, которым она компилена) зависит практически ВСЕ что касается избыточности
В принципе может, но в реальности - практически нет... Я же не просто так написал, неподумав - мы эту тему давно обсуждали с одним моим знакомым.
Во тебе еще пример - у меня есть прога на VC++ с использованием MFC. Эта программа занимается тем, что генерирует код морзе на звуковухе (писалась для военной кафедры). На release версии стоит "use MFC in a static library" (т.е. еще и MFC там!). Итак, я беру секцию .text и записываю ее в отдельный файл. Она занимает 17996h байт (35222 по десятичному). Архивирую winrar (как обычно, максимальная степень сжатия) - 19 962! Т.е. 56%, как я и говорил, чуть хуже, чем прога на асме (для желающих - см. вопрос № 3335).
Далее. Беру программу измерения скорости чтения файлов с диска. Написана на VC++ без всего стандартного, т.е. чистый код (методика описана на моей странице). Секция .text занимает 3 590, после архивации - 2 070 (57,7% - завидное постоянство!).
Далее, берем HTTP сервер, который я написал на VC++ также без всего лишнего (его можно скачать с моей страницы, чтобы проверить). .text занимает в нем 10 384, в архиве - 5 759, т.е. 55,6%, опять-таки почти одно и то же...
Ну и теперь Delphi:
программа, которая ничего не делает (почти), секция code - 315 012 байт (если все туда включить) - о как! После сжатия - 141 377, т.е. 44,9%. Вот уже хуже, но не намного! Но в асме-то я получил около 42%, т.е. все же больше!
Но в том же дельфи я не смог добиться приложения меньше 360 кб, так что это в основном библиотеки.
> Избыточность асмовских прог определяется только стилем написания и зависит от программиста.
Не соглашусь со словом "только". Некоторые команды несут больше избыточности, некоторые - меньше.
> Впринципе, если сильно поискать то где-нить в "Теории трансляци" можно найти доказательство того, что компиленный исходник с языка высокго уровня намного избыточнее чем машинный код (читай - асм), хотя это и так ясно интуитивно.
Если провести исследование, получится как раз наоборот! Поясню - возьмем за основу VC++ и его мощный компилятор, и, естесвенно, только release-версию программы. VC оптимизирует то, что не один нормальный программист на асме оптимизировать не станет! Вот пример - всем известно, что ни одна API функция не меняет значение регистров ebx, esi, edi - если в подпрограмме встретится два или больше вызова одной и той же функции (в то же время вычислений будет мало), то VC поместит ее адрес в один из вышеназванных регистров и сделает два раза, например, call ebx. Это даст экономию памяти в несколько байт. Будешь ты писать так на асме? И я не буду. Далее, много функий принимают нули в качестве параметров. push 0, обычно встречающийся в прогах занимает 2 байта, в то время как push ebx - 1. Вот тебе экономия по одному байту на один нулевой параметр, начиная с третьего (еще xor ebx, ebx нужен - 2 байта). В общем, компиляторы с ЯВУ скоро станут лучше оптимизировать, чем программист, т.к. очень сложно писать программу, ловко оперируя регистрами и подсчитывая количество занимаемых байт (да ведь я еще все вышеприведенные проги на скорость оптимизировал, а не на размер!).
> Рискну предположить, что у тебя был избыточный стиль написания - много CALL-ов, одни и те же параметры перед вызовом, возможно применял макросы (?)
Нет, макросов не было. Call'ов было ровно столько, сколько бы и на такой же программе на C++, параметры - такие же. Нет причина именно в том, что я не оптимизировал в регистры нули и адреса функций, ну ... и может еще в чем-то.
> Вообщем, конечно я может утрирую, но возьми ЛЮБОЙ исходник с hugi.de/compo сожми его ЛЮБЫМ алгоритмом сжатия
Да, надо бы попробовать. Но то, что есть там уже нельзя назвать чистым ассемблером, т.к. там специально сидят и думают, как бы сделать прогу поменьше (часто не обращаю внимание на падение скорости).
> и возьми ту же самую прогу на С
Тоже надо попробовать.
* EMan1.1: ---===*** Eternal power ***===---
Ответ отправлен: 06.06.2003, 21:27
Отправитель: Bob Johnson
Отвечает masquer
Доброе время суток, Broken Sword!
Тут кратко выскажусь - все зависит от стиля написания, можно как раздуть прогу на асме, так и сжать. Хотя, хоть убейте, не пойму о чем вообще спор?
Ответ отправлен: 08.06.2003, 11:56
Отправитель: masquer
Отвечает Maverick
Здравствуйте, Broken Sword!
Даа, там есть чему поучиться (на hugi.de/compo)
Полностью согласен.
Ответ отправлен: 07.06.2003, 04:52
Отправитель: Maverick
Вопрос № 3389 |
>VC поместит ее адрес в один из вышеназванных регистров и сделает два раза, например, call ebx. Это даст экономию памяти в несколько байт
... тем не менее, никакие подобные ухищрения даже на порядок не дают приблизиться к скорости и размерам на асме
компиляторы с ЯВУ скоро станут лучше оптимизировать, чем программист
это интересный вопрос
хочу только отметить, что на процах с архитектурой IA-32 этого не будет никогда, потому как такого не может быть в принципе на процессоре, в котором "...регистры можно пересчитать на пальцах рук и ног".
Безусловно, утверждать, что на асме нельзя соптимизировать так как это сделает компилятор абсурдно. Все что может компиллятор - может сделать и человек, но не все что может человек сможет компиллятор (по крайней мере на сегодняшний день).
конечно, в Itanium-ах отношение
ресурсы_затраченные_на_написание_проги_на_асме/полученный_выигрыш_в_скорости_и_размере еще более возрастет и на процессорах через несколько поколений вообще будет стремиться к бесконечности, однако нам повезло :) - в IA-32 он держиться на уровне единицы, поэтому пока не поздно нужно ловить момент истины и всем программить на асме )
(интересно также отметить откуда взялся такой вывод - из вопроса о сжатии)
Вопрос отправлен: 06.06.2003, 22:11
Отправитель: Broken Sword (brokensword@mail.ru)
[Следующий вопрос >>] [Список вопросов]
Отвечает Bob Johnson
Приветствую Вас, Broken Sword!
> в котором "...регистры можно пересчитать на пальцах рук и ног"
Это точно. РОН здесь, как это не странно, меньше, чем в Z-80 (по количетву).
> Безусловно, утверждать, что на асме нельзя соптимизировать так как это сделает компилятор абсурдно
Естественно, потому что на выходе компилятора и будет асм... Я имею ввиду то, что никто из нормальных программистов не сможет написать в таком стиле ни одну серьезную программу (умрет в процессе - постпримечание).
> но не все что может человек сможет компиллятор
Тоже согласен (SSЕ, например).
Это все правильно и никто с этим не спорит. Но мы же говорим о реальных вещах - т.е. о программах, которые используют функции и т.д. Избыточность средне-оптимизированного кода таких программ, написанных на асме будет на уровне (или нескольо выше), чем такой же программы, но написанной на С++.
Да, совсем забыл сказать, что я имею (и имел) в виду только 32-разрядные программы! В них избыточность значительно больше, чем в 16-разрядных, т.к. любой адрес, полное смещение или полные данные занимают по 4 байта, в то время как в 16-разр. по 2. Вот это, видимо, и является наибольшим источником избыточности (т.к. если смещение при jmp или call не превышает по модулю 32767, но больше 128, то формируется 4-х байтное смещение, у которого два старших байта 00 или FF). Я заметил еще давно, что в моих программах, написанных на асме очень много нулей (в откомпилированном коде). Мое мнение при этом, что избыточность в коде программ - вещь неизбежная и не сильно зависящая от компилятора, а скорее - от разрядности и архитектуры процессора (да, действительно на спектруме избыточности в коде почти не было...)
> (интересно также отметить откуда взялся такой вывод - из вопроса о сжатии)
Ты имеешь ввиду "компиляторы с ЯВУ скор..." - это из личного опыта. Тут речь идет о среднем значении среди большинства программистов - т.е. чтобы писать грамотные и оптимальные программы на асме нужно обладать огромнейшими знаниями процессора, под которых пишешь - регистры, конвейеры, стек, время выполнения в тактах, размер, кэш и т.д. А процессоры постоянно совершенствуются и вряд ли даже из программистов на асме хотя бы 25% совершенствуется вместе с ними (на том же уровне). А компилятор с того же С++ может трезво держать в "голове" все особенности процессора и применять их по максимуму. К сожалению, мы "вымераем" :( как это ни печально... А иначе почему думаешь NVidia придумала Cg вместо pixel shader? Да именно потому, чтобы общий уровень программ (точнее, шейдеров) поднялся, т.к. чем мощнее процессор, тем меньше людей могут его достойно использовать (известная вещь - сумма интеллекта программиста и компьютера есть число постоянное, независящее от времени).
> поэтому пока не поздно нужно ловить момент истины и всем программить на асме
Блин, к сожалению, прошло это время уже... Нет, писать на асме можно и сейчас, но как ты сам сказал, отношение время/качество уже значительно больше 1 (т.к. если напишешь быстро - значит "кое-как", если медленно (и качественно) - значит экономически невыгодно...) (но что это я тут написал? рассылка-то по ассму!!!!! исправим :)
Но это совсем не значит, что асм не надо изучать! Такое мнение очень и очень ошибочно! Асм нужен любому более-менее серьезному программисту (для отладки, взлома и т.д.) Тем более, что если писать на асме отдельные кусочки кода, то отношение время/качество может быть и значительно ниже 1 (кусочки небольшие, но важные), тем более, что SSE и MMX, насколько я знаю, не используются ни одним распространенным компилятором. (imho, их будет использовать проще из пролога и лиспа (и т.д.), чем из С++). Пример - всеми известный и применяемый (кто еще делает MP3) LAME Encoder - весь написан на С++, кроме основных моментов, которые есть на MMX (даже, кажется, на SSE есть).
* EMan1.1: ---===*** Eternal power ***===---
Ответ отправлен: 07.06.2003, 18:31
Отправитель: Bob Johnson
Отвечает masquer
Добрый день, Broken Sword!
Флеймовая тема, но выскажусь...
Цитата - компиляторы с ЯВУ скоро станут лучше оптимизировать, чем программист
Дык вот хрен, скажу я вам. So far я еще не видел ни одного компилятора (за одним единственным исключением) который бы выдал мне код, лучше (в данном случае - быстрее) которого я не напишу. Последних года полтора я занимаюсь со всякими мудреными алгоритмами, большинства из которых на асме не было (по крайней мере - я не нашел), все они берутся в основной с сишных сорцов. Так вот не увидел я ничего оригинального в том коде который делают компилеры. И пока дойдет дело до Itanium2 c его 500 регистрами (или около того) я имею честь заявить что нет такого компилятора, который однозначно напишет код лучше, чем грамотный программист. Почему, даже объяснять не буду.
О, нажал кнопку подробнее - ни одну серьезную программу (умрет в процессе - постпримечание)
Во-первых, что значит - серьезную, что именно определяет слово серьезная - тут надо уточнение - ато я сейчас пишу прогу - 300 кб чистого асмового кода, около 300 функций, столько же структур. Пока стиль держу. :)))
Отношение время/качество - я пишу чуть-чуть быстрее на асме, чем многие на С с ВинАПИ - хе-хе, набираю быстро.
экономически невыгодно - это высказывание еще более сомнительно.
Intel C использует и MMX и SSE2.
Боб, сори, одни нападки на тебя, но больше ответов нет :))
Ответ отправлен: 08.06.2003, 12:09
Отправитель: masquer
Вопрос № 3390 |
Здравствуйте, уважаемые эксперты! Вопрос не по ассемблеру как языку, а по работе отладчика.
Я пользуюсь отладчиком SoftIce. Полное название: SoftIce Driver Suite v.2.0.1. У меня не работают
следующие команды: все команды оканчивающиеся "A" (например, bpx MessageboxA,bpx MessageBoxIndirectA), а также (bpx readfile,bpx createfile).
Cкажите как решить эту проблему. Буду очень признателен.
Вопрос отправлен: 06.06.2003, 22:50
Отправитель: Mafia
[Следующий вопрос >>] [Список вопросов]
Отвечает --- Нет данных ---
Доброе время суток, Mafia!
Попробуй в файле winice.dat в самом конце сделать чтобы закомментированные строки были незакомментированными =)
т.е. убрать ";" перед всеми строками начинающимися на EXP=SystemRootSystem32
Ответ отправлен: 07.06.2003, 00:09
Отправитель: --- Нет данных ---
Отвечает Bob Johnson
Доброе время суток, Mafia!
А версия Windows у тебя какая, не слишком ли старый Soft Ice для нее? И еще, ему надо прописать функции в специальном файле, кажется winice.dat, у тебя это сделано?
* EMan1.1: ---===*** Eternal power ***===---
Ответ отправлен: 07.06.2003, 18:31
Отправитель: Bob Johnson
Вопрос № 3391 |
Zdravstvuite Tovarish MozgC.
// Tut vi pisali pro patch k SoftIce.
Ya tut shaz ego kachayu s belarusskogo servera.
Po semu voproshayu - ne mogli bi vi PLS prislat' mne k nemu crack pro kotoriy vi pisali.
C YBA}|{EHUEM!
Вопрос отправлен: 07.06.2003, 09:10
Отправитель: Edward (edsam@spidernet.com.cy)
[Следующий вопрос >>] [Список вопросов]
Отвечает --- Нет данных ---
Доброе время суток, Edward!
Я писал не про crack, а про патч.
Этот патч необходим для нормальной работы SoftICE под Windows XP
Вот ссылка :
http://MozgC.narod.ru/files/XPpatch.zip
Файлы необходимо распаковать в
Windowssystem32drivers уже после установки SoftIce
Удачи!
Ответ отправлен: 07.06.2003, 11:20
Отправитель: --- Нет данных ---
Вопрос № 3393 |
Здраствуйте уважаемые эксперты!
Подскажите, пожалуйста, как на ассемблере
без использования АПИ функций (и вообще всего что
относится к винду) перегрузить и выключить систему.
Все это должно происходить в винде.
У меня есть пример по перегрузке, но он не
работает. Все компилируется, но при запуске
выдается ошибка.
Заранее всем спасибо!
С уважением, Sammy
Приложение:
Вопрос отправлен: 07.06.2003, 11:02
Отправитель: Sammy (sfxgt666@yahoo.com)
[Следующий вопрос >>] [Список вопросов]
Отвечает --- Нет данных ---
Добрый день, Sammy!
Смотри пример в приложении
Ответ отправлен: 07.06.2003, 16:55
Отправитель: --- Нет данных ---
Отвечает Hangatyr
Доброе время суток, Sammy!
Под виндой и без использования API?
Например, так:
...
mov al, 0FEh
out 64h, al
...
Но для того, чтобы это прокатило понадобятся системные привилегии, т.е. надо будет написать драйвер или перейти в Ring0 одним из недокументированных способов.
Ответ отправлен: 07.06.2003, 11:38
Отправитель: Hangatyr
Отвечает _vt
Приветствую Вас, Sammy!
Во-первых, этот код не может скомпилироваться! Тут есть ошибки; во-вторых, если все исправить, то он будет выполняться только под чистым DOS, а не под Windows; в-третьих, IMHO, корректно перезагрузить компьютер под Windows можно только через API или вызовом через командную строку rundll32.exe с параметрами(что в принципе одно и тоже). В приложении пример для Win98.
Приложение:
Ответ отправлен: 07.06.2003, 14:09
Отправитель: _vt
Отвечает Tigran K. Kalaidjian
Добрый день, Sammy!
ИМХО никак. По крайней мере с помощью ассемблера.
Ответ отправлен: 07.06.2003, 20:52
Отправитель: Tigran K. Kalaidjian
Отвечает masquer
Здравствуйте, Sammy!
Гы, а никак, да еще и без АПИ. Досовский метод может и прокатит, и то, разве что под 95.
Ответ отправлен: 08.06.2003, 12:36
Отправитель: masquer
Отвечает Дмитрий
Приветствую Вас, Sammy!
ИМХО, никак!
Ответ отправлен: 09.06.2003, 13:42
Отправитель: Дмитрий
Отвечает Bob Johnson
Приветствую Вас, Sammy!
Ну и что ты хотел? Винда перехватывает все ключевые моменты управления компьютером, поэтому чтобы перезагрузиться в общем случае надо использовать ее функции.
* EMan1.1: ---===*** Eternal power ***===---
Ответ отправлен: 07.06.2003, 18:31
Отправитель: Bob Johnson
Форма отправки вопроса |
Мы рекомендуем открывать рассылку в программе Internet Explorer 5.0+ или отправлять вопросы с сайта по адресу: http://rusfaq.ru/cgi-bin/Message.cgi.
(C) 2002-2003 Команда RusFAQ.ru.
Вопрос и дополнение |
Ваш вопрос:
Приложение (если необходимо):
Получить ответов:
Выбор рассылки |
Программисту Assembler (34) C / C++ (29) Perl (7) Builder / Delphi (18) Pascal (29) Basic / VBA (12) Java / JavaScript (12) PHP (8) MySQL / MSSQL (7) |
Пользователю Windows 95/98/Me (36) Windows NT/2000/XP (31) "Железо" (26) Поиск информации (15) |
Администратору Windows NT/2000/XP (16) Linux / Unix (9) |
Юристу Гражданское право (6) Семейное право (2) Трудовое право (3) КоАП (3) |
Отправить вопрос всем экспертам выбранной рассылки.
Проект экспертов RusFAQ.ru | Фотоальбом | Virus.RusFAQ.ru | Администрирование
© 2001-2003 Россия, Москва. Авторское право: Калашников О.А. |
http://subscribe.ru/
E-mail: ask@subscribe.ru |
Отписаться
Убрать рекламу |
В избранное | ||