1 |
Здравствуйте, Максим! |
2 |
|
3 |
> Я далек от глубоких познаний в работе операционных систем, такчто |
4 |
> заранее извиняюсь, если мои вопросы покажутся глупыми. Что делают |
5 |
> программы? Они либо вызывают API ОС либо выполняют математические |
6 |
> действия. Раз ядро портировали скажем на ia64, то значит оно обеспечит |
7 |
> вызов всех своих API функций именно на этом железе. Вопрос с |
8 |
> математикой должен решаться компилятором, флагом -mcpu=****, тогда |
9 |
> любое мат. выражение, скажем, на С будет переведено в комманды |
10 |
> ассмеблера именно для этой платформы. Т.е. портирование любых прог, |
11 |
> теоретически должно происходить простой компиляцией, но этого не |
12 |
> происходит - почему? |
13 |
|
14 |
|
15 |
Тут возникает такая проблема: скажем, программа занимается стеганографией |
16 |
(метод шифровки). Надо взять байт шифруемого материала, разбить на биты и |
17 |
рассовать эти биты по байтам какого-нибудь другого файла. Проблема в том, что |
18 |
компилятор для математических и некоторых других операций (например, |
19 |
бинарного сдвига) преобразует байт в int. На x86 можно с помощью memcpy() |
20 |
скопировать первый байт (который является младшим) в структуру с битовыми |
21 |
полями и уже потом манипулировать битами. Но если комп не x86, а, скажем, |
22 |
PPC, то младший байт - не первый, а последний, и программа не будет на этой |
23 |
архитектуре работать как надо. С этим я сам недавно столкнулся - проблема не |
24 |
из приятных. |
25 |
|
26 |
Другая проблема - наличие ассемблерного кода или другого вида низкоуровневой |
27 |
оптимизации (чаще всего - в видео- и аудиоплеерах). Рост производительности |
28 |
засчет потери портабельности. |
29 |
|
30 |
Вообще же, если прога компилится на всех архитектурах - значит автор писал ее |
31 |
грамотно, не отступал от стандартов и задумывался о портируемости. К |
32 |
сожалению, не все программисты выполняют все 3 требования. |
33 |
|
34 |
С уважением, |
35 |
Глеб |
36 |
|
37 |
-- |
38 |
gentoo-user-ru@g.o mailing list |