Linux.by

vics писал(а):
Victor Gr. писал(а):Интересует чему посвятить себя, чтобы в перспективе за окном стоял свой Porsche
Купи-продай (желательно госсобственность).

или ширпотреб в огромных количествах...

Foxx, ну, да, ключи есть. А реально они применяются когда? Компилятор эффективно применяет?

Victor Gr. писал(а):Чем это лучше, чем направить системный вызов операционной системе?

Ну можно и прямо в видеопамять написать, но так уж полностью переносимость теряется. Зато, самый быстрый код!

А ты слышал о разнице в передаче параметров системным вызовам между Linux и *BSD например? Какая уж тут переносимость... И самый быстрый код обеспечивается не ASM'ом, а правильно выбранным алгоритмом, как это не порадоксально

Victor Gr. писал(а):Ну и так далее. Это самый простой пример.

Пример чего?

Victor Gr. писал(а):Foxx, ну, да, ключи есть. А реально они применяются когда? Компилятор эффективно применяет?

Они применяются, когда ты их в командной строке укажешь, вообще-то.

"Чем это лучше, чем направить системный вызов операционной системе? "
Тем что при прямом системном вызове вывод программы не сможет быть перенаправлен.
Как следствие -- она останется негибкой сущностью в себе, и не станет инструментом unix.

Victor Gr. писал(а):Foxx, ну, да, ключи есть. А реально они применяются когда? Компилятор эффективно применяет?

реально применяются, если нужна прямая поддержка мат. расширений, не поверите.
компилятор? применяет эффективно. насколько может он и насколько способен программист

мне кажется такие вопросы абсурдны, ибо противоположные ответы на них просто не имеют смысла. зачем было бы вводить доп. параметры компиляции, для понтов что ли?

Victor Gr. писал(а):Читаю книжки по ассемблеру, оптимизации программ (с учётом особенностей архитектуры процессоров x86) и рядом с ними - по MySQL и PHP.

Читаю, и параллельно размышляю: а как сейчас востребованы специалисты по низкоуровневому программированию? Нужны ли сейчас люди хорошо разбирающиеся в ассемблере и тонкой заточке кода под архитектуру?

Другими словами, можно ли получать хорошие деньги, быть востребованным, посвятив себя ассемблеру?

Или же в наши дни скорость и требования в разработке программ сменились и гораздо важнее уметь создавать правильные базы данных, писать качественные скрипты и заниматься веб-программированием?

Интересует чему посвятить себя, чтобы в перспективе за окном стоял свой Porsche

а я щас читаю Ю.С.Лукач, А.Е.Сибиряков А Р Х И Т Е К Т У Р А В В О Д А - В Ы В О Д А П Е Р С О Н А Л Ь Н Ы Х Э В М I B M P C (1990). Очень интересна книга:( Рекомендую

И самый быстрый код обеспечивается не ASM'ом, а правильно выбранным алгоритмом, как это не порадоксально

Согласен с вами.

Они применяются, когда ты их в командной строке укажешь, вообще-то.

Просто хотелось узнать, всегда ли компилятор определяет необходимость использования MMX-расширений. Что для человека видно явно, то компилятор может определить только логикой.

Тем что при прямом системном вызове вывод программы не сможет быть перенаправлен.

Благодарю за точный ответ! Почему так происходит - уже буду разбираться сам.

а я щас читаю Ю.С.Лукач, А.Е.Сибиряков А Р Х И Т Е К Т У Р А В В О Д А - В Ы В О Д А П Е Р С О Н А Л Ь Н Ы Х Э В М I B M P C (1990). Очень интересна книгаSad Рекомендую[/qoute]

Благодарю за рекомендацию!
Вопрос: не слишком ли многое изменилось со времен 1990-х годов в архитектуре IBM PC?
PCI, AGP, Hyper-Transport, USB и прочие нововведения?

Либо эта книга совсем о другой области?

// sorry for english, just don't have a cyrillic layout at hand

sanitar писал(а):"Чем это лучше, чем направить системный вызов операционной системе? "
Тем что при прямом системном вызове вывод программы не сможет быть перенаправлен.
Как следствие -- она останется негибкой сущностью в себе, и не станет инструментом unix.

Yep?

so smth like the following scenario:

--- prog.c
#include <unistd.h>

int main()
{
const char text[] = "Hello, World!";
write(STDOUT_FILENO, text, sizeof(text)-1);

return 0;
}
---

./prog | grep "Hello"

won't work?

let's find smth more "ugly". what about this one

)

http://www.diku.dk/hjemmesider/studeren ... 0000000000

doesn't work?

речь не шла о вызове write
посмотрел бы я на перенаправление fcntl(), unlink() или rmdir()

речь шла о принципах взаимодействия приложений в user-space

[skip]

ok, the answer then would be as follows:

the printf() library call is, no doubts, much more better than a system call like mlockall() because with the later one (at least, with its standard implementation) there are no chances to get "Hello World!" printed out (as a side effect, nothing to be redirected).

i/o redirection. I'd like to know what kind of "redirection" you might use with unlink().

So what kind of inter-process communication in user-space has been meant in the context of the original question and answer?

Victor Gr. писал(а): Благодарю за рекомендацию!
Вопрос: не слишком ли многое изменилось со времен 1990-х годов в архитектуре IBM PC?
PCI, AGP, Hyper-Transport, USB и прочие нововведения?

а оно тебе надо?

Victor Gr. писал(а): Либо эта книга совсем о другой области?

вот зайди на http://wasm.ru/publist.php?list=22 там много чего интересного

В продолжение темы:

выдержка с форума ixbt.com

>> i386DX40, i486DX4-100, A5х86-133 - есть ли сейчас место под солнцем?

Интересный вопрос ответ на него проще всего искать в годовом отчете
по рынку процессоров.
За этот год не видел еще а вот за прошлый:
70% дохода принесли эти древние процы, и даже более простые 8086 8080 и.т.д
Если считать в штуках так вообще вопрос надо ставить есть ли место для Pentium 4?
Для управление базовой станцией используется проц типа 8086.
Для приемников GPS используютс эти же древние процессоры.
СВЧ печь тоже эти процы.

Так ли??

Нетак. Z80 еще жив, + в связи с увеличением ресурсоемкоси современного встраиваемого софта (в связи с необходимостью ускорения разработки) все больше продается нормальных маленьких процессоров типа ARM, SPARC и т.п.

Linux.by

Нужны ли специалисты по низкоуровневому программированию?

Re: Нужны ли специалисты по низкоуровневому программированию

Re: Нужны ли специалисты по низкоуровневому программированию