Linux or Windows?

уменшается количество инструментов для разработки программ.

 

rei3er

На самом деле никаких трудностей -- весь "поддерживающий" код простой и короткий (порядка сотни строк на ассемблере; если желаете, могу кинуть оригинал из RSX-11M). Так что этот довод, как и упрощение архитектуры, здесь не проходит.

Что же касается "а для чего", ответ простой до безобразия: производительность. Меньший расход памяти сам по себе неплох (и доводы, что-де сейчас ОЗУ в 2 Гб никого не удивишь, не проходят: копейка рубль бережёт, как известно, ну а этот механизм -- лишь один из многих, которые можно и нужно оптимизировать, ведь современные ядра "жирны" до безобразия), ну а экономия на стеках режима ядра приводит к уменьшению числа перезагрузок кэша, которые иначе будут происходить постоянно (ведь контекст переключается при каждом прерывании -- сотни, а то и тысячи раз в секунду на современных компах). Вам-то объяснять, думаю, не надо, насколько существенным это может оказаться для производительности.

 

SII, писал:

Месье SII может привести названия этих "разных платформ", или в качестве мерила выступает динозавры 70-ых PDP-11 или VAX, давным давно канувшие на cвалках, в том числе истории?

Не сочтя за труд натравить поиск в FAR-е на inb/w/l, outb/w/l на исходники ядра Linux, в /ARCH/ единственное где не удалось обнаружить их применение - это разве что в малопопулярной архитектуре SPARC/SPARC64, в некоторых случаях использовалась различная HLL обертка, типа ctrl_out/b/w/l, ctrl_in/b/w/l в SH,SH64 или master_inb в M68K, дефайненое как

Прошу заметить Линус Торвалдс за свой почин уже имеет, 1 000 000 $, и в то время как некоторые рассуждают про "моя система нипель" круче вындопс-мастдая и отсталых никсов, исписывая километры мало кому упавшего голословного оффтопа, Linux продолжал и продолжает остоваться базовым фундаментом для многофункциональной ОСИ, и! Единственным Источником Информации, программирования для low-level кодеров...

Винда же от мелкопакостных обдолбаных индусов (перекуривших VB/Ole быдлокода), несмотря на обеспеченость ПО (анд кряками), так и останеться саксом, из за своей гнилой и геморной COM/ActiveX архитектуры, в том числе и на уровне WDM ядра, которым рулят разве что избранные гиганты Win32/64 мысли (у мну стоят Open-Source драйвера под древний tv-tuner AVER307, и дешовую звучку CMI8738, с воистину мраковым кодом на C++)...

В Linux-е то хотябы есть еще, ортодоксальная чистота, не испоганеная C++...


rei3er писал:

чепуха, крутые кулкодеры к примеру аффтары QEMU как посмотришь, делают на GCC так просто финты ушами..

Код (Text):

1. /*******************************************/
2. /* host CPU ticks (if available) */
3.  
4. #if defined(__powerpc__)
5.  
6. static inline uint32_t get_tbl(void)
7. {
8.     uint32_t tbl;
9.     asm volatile("mftb %0" : "=r" (tbl));
10.     return tbl;
11. }
12.  
13. static inline uint32_t get_tbu(void)
14. {
15.     uint32_t tbl;
16.     asm volatile("mftbu %0" : "=r" (tbl));
17.     return tbl;
18. }
19.  
20. static inline int64_t cpu_get_real_ticks(void)
21. {
22.     uint32_t l, h, h1;
23.     /* NOTE: we test if wrapping has occurred */
24.     do {
25.         h = get_tbu();
26.         l = get_tbl();
27.         h1 = get_tbu();
28.     } while (h != h1);
29.     return ((int64_t)h << 32) | l;
30. }
31.  
32. #elif defined(__i386__)
33.  
34. static inline int64_t cpu_get_real_ticks(void)
35. {
36.     int64_t val;
37.     asm volatile ("rdtsc" : "=A" (val));
38.     return val;
39. }
40.  
41. #elif defined(__x86_64__)
42.  
43. static inline int64_t cpu_get_real_ticks(void)
44. {
45.     uint32_t low,high;
46.     int64_t val;
47.     asm volatile("rdtsc" : "=a" (low), "=d" (high));
48.     val = high;
49.     val <<= 32;
50.     val |= low;
51.     return val;
52. }
53.  
54. #elif defined(__ia64)
55.  
56. static inline int64_t cpu_get_real_ticks(void)
57. {
58.     int64_t val;
59.     asm volatile ("mov %0 = ar.itc" : "=r"(val) :: "memory");
60.     return val;
61. }
62.  
63. #elif defined(__s390__)
64.  
65. static inline int64_t cpu_get_real_ticks(void)
66. {
67.     int64_t val;
68.     asm volatile("stck 0(%1)" : "=m" (val) : "a" (&val) : "cc");
69.     return val;
70. }
71.  
72. #elif defined(__sparc_v9__)
73.  
74. static inline int64_t cpu_get_real_ticks (void)
75. {
76. #if     defined(_LP64)
77.         uint64_t        rval;
78.         asm volatile("rd %%tick,%0" : "=r"(rval));
79.         return rval;
80. #else
81.         union {
82.                 uint64_t i64;
83.                 struct {
84.                         uint32_t high;
85.                         uint32_t low;
86.                 }       i32;
87.         } rval;
88.         asm volatile("rd %%tick,%1; srlx %1,32,%0"
89.                 : "=r"(rval.i32.high), "=r"(rval.i32.low));
90.         return rval.i64;
91. #endif
92. }
93. #else
94. /* The host CPU doesn't have an easily accessible cycle counter.
95.    Just return a monotonically increasing vlue.  This will be totally wrong,
96.    but hopefully better than nothing.  */
97. static inline int64_t cpu_get_real_ticks (void)
98. {
99.     static int64_t ticks = 0;
100.     return ticks++;
101. }
102. #endif
103.  
104. /* profiling */

И прошу заметить что Изначально, тема касаеться двух оч. популярных МЕЙНСТРИМОВ...
Наверно стоит поговорить про синиц/пингвинов в руках, которые уже СОСТОЯЛИСЬ, чем скролить байки из склепа про афигительно-быструю RSX-11... на ASM-е для PDP-11...
и мега-отстойные х86 процики, с постоянно сбрасывающимся TLB и промахах в кэше...
Почему то покурив исходнечки под другие процы, ничего кроме как сочуствия отважным кодерам в пустыне, не возникает..

 

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

 

rei3er

Никак нет Подобное снижение производительности происходит только в определённых ситуациях, которых зачастую можно избежать. Ну а когда нельзя -- не удастся избежать и в линуховой архитектуре (если надо получить доступ к адресному пространству другого процесса -- придётся этот доступ получать независимо от того, каким макаром используется стек, а значит, будем иметь точно те же самые последствия вроде необходимости перезагрузки TLB).

В общем, главная проблема состоит в том, что "натурные испытания" двух подходов устроить проблематично: ведь если переделывать обработку прерываний на "мою" технологию, придётся переписать половину, если не всё ядро Линух -- а тогда мы получим миллион других факторов, влияющих на производительность, т.е. не будет чистоты эксперимента.

bugaga

Если бы Вы, господин наркоман и матерщинник, были бы чуть-чуть немного более грамотным технически, Вы бы знали, что архитектура ввода-вывода VAX-11 и тем паче PDP-11 просто изумительно "ложится" на тот же Линух или Вындовз для IA-32. Правда, на той же PDP-11 для доступа к внешним устройствам используется адресное пространство памяти (её старшие 8 Кб), но от замены in/out на mov ничего не меняется -- разве что возможность использования и других арифметическо-логических команд позволяет создать чуть более компактный и быстрый код, чем с помощью одних mov'ов.

У Вас, возможно, SPARC'и и не пользуются популярностью, да и трудно спорить, что их производится несколько меньше, чем IA-32, да только почему-то очень многие использовали, используют и собираются и в будущем продолжать использовать эту платформу. А что лично Вам плевать на всё, кроме IA-32, это лично мне давно известно.

Ну а в качестве альтернативной системы ввода-вывода можете для интереса -- если осилите, конечно, это не травку курить -- почитать описание архитектуры тех же IBMовских мэйнфреймов zServer, они же ESA/390. Нет, и для них Линух существует и благополучно работает -- только изрядная порция кода, естественно, была переписана. Только попрошу не забывать, я никогда не утверждал, что Линух нельзя куда-то там перенести. Я всего лишь утверждаю, что нельзя добиться переносимости простым переписыванием нескольких библиотечных функций.

Если лично Вы нигде, кроме как в Линухе, достать информацию не способны, -- это Ваши личные проблемы. Мне как-то пока хватало информации из других источников.

Что же касается денег г-на Торвальдса, то он их заработал вполне честным образом. Правда, хозяин столь любимого Вами "быдлософта" несколько более богат, но это мелочи.

О да, мы с уважаемым rei3er зафлуживаем рассуждениями "около темы" уже не первую тему

Кому что интересно. И, между прочим, не моя вина, что RSX-11 действительно была "афигительно-быстрой" системой, хотя на той же PDP-11 была и ещё более быстрая (но и существенно более простая) RT-11.

 

rei3er

для яву ф-ции нужны три параметра - всё остальное это настройки по дефолту впаяные в асм код под кокретный проц, более того, компиль будет сам ставить эти дефолтные значения, ввиду надобности экономии времени или памяти.

 

bugaga

один пример не доказывает мою неправоту
это раз
во-вторых, представлена реализация get-функции без параметров, а это наиболее примитивный вид функции
если получение некоторой функциональности семантически ложится на такой тип функции, то согласен, универсальную функцию написать можно
но в большинстве случаев написать универсальную сигнатуру без элипсисов или множественных параметров
не получится, использование же их выливается в потерю переносимости
кроме того, в который раз говорю, множества семантик инструкций разных архитектур могут не иметь пересечений
SII

copy_from_user(), put_user() в Linux работают в контексте текущего процесса
т. е для их реализации используется обычный mov + проверка правильности адреса
тут даже дело не в стеке, а в том, что в Linux абсолютно все выполняется в контексте некоторого процесса

 

потеря переносимости на уровне исходного кода из-за подстройки

 

rei3er

Эти функции осуществляют пересылку в контексте текущего процесса или в контексте любого процесса, который им укажут?

 

rei3er

c какого перепуга) ===>> сама яву функа имеет общий вид: LowLevelIo(number_port, size_data, data), а подстройка - это вопрос реализации компиля под конкретный камень

 

UbIvItS

А если к устройствам обращение идёт не через порты и не через ячейки памяти?

 

SII
а как?

 

UbIvItS

Например, так.

Для запуска операции ввода-вывода на некоем устройстве программа должна сделать следующее:

1. Создать в оперативной памяти канальную программу -- последовательность 8-байтовых слов, выровненных на границу 8 байтов, каждое из которых кодирует одну конкретную операцию для устройства (например, чтение данных из текущей записи диска), указывает адрес буфера ввода-вывода, длину передаваемых данных, а также содержит флаги, управляющие продолжением или прекращением канальной программы при определённых условиях.

2. Записать адрес начала канальной программы в определённую ячейку оперативной памяти.

3. Выдать команду SIO (начать ввод-вывод), в которой указать адрес устройства, на котором начинается операция.

4. Проверить успешность запуска операции по состоянию, возвращённому SIO.

 

Откуда это? Что - то очень знакомое.
Похоже на Дос.

Код (Text):

1. DRIVE_C =2
2. ; формируем блок параметров
3. .data
4. paramBlock label byte
5. sectorNumber dd 00
6. sectorCount dw 1
7. bufferOfs dw buffer
8. bufferSeg dw data
9.  
10. .code
11. mov al, DRIVE_C
12. mov bx, offset  paramBlock ; указываем на блок
13. mov cx, 0FFFFh ; адрес устройства
14. int 25h
15. .......

 

reiser, писали:

Вам мож и не доказыает, а мне, допустим, доказывает)))

Тем более что QEMU - шедевр на C99, портирован под весь указаный парк процессоров, с сумарным обьемеом текста 10 мегабайт.

А вот единственное что там "вылилось в потере переносимости" - в моей практике, траханья с этим проектом - так это полный облом со сборкой WinNT драйвера-ускорителя KQEMU, сперва на стадии сборки. Сперва AS ругался (помогли грязные хаки сорцов), и потом на стадии линковки, полный тупик с LD который ниасилил собрать в кучу обектники... В дистрибуте лежит уже готовый KQEMu.sys, видать собраный реальными кернел-хакер-девелоперами

Извините, многа букв - ниосилил..

SII, писали:

А какое отношение имеет программирование подрубаемой перефирии к ЯВУ и к операциям ввода/вывода? Тем более что единственно возможный способ обмена, в практически любых CPU - это запись/чтение либо в ячейки памяти, либо в специфическое адресное пространство именуемое портами...

 

bugoga

рад за вас

вы вообще понимаете, о чем мы говорим?

извиняю
прежде, чем продолжить, обратите внимание на предыдущий вопрос и все-таки осильте мой пост

ключевое слово практически

 

reiser, писали:

C учетом приведенной Вами, выше моей цитаты:

я полагаю что мы говорим про ПО QEMU - эмулятор
аппаратных платформ на базе: arm, i386, m68k, mips, ppc, sh4, sparc...

А можно уточнить какой именно?

Ну опять же это все теория и демагогия не имеющие ничего общего с суровой практикой,
в которой как мы видим, cool-coder's пишут километры кросплатформенного текста, не волнуясь за то, что:

Весьма содержательное замечание...

 

budaga
разговор начался вот с этого
http://www.wasm.ru/forum/viewtopic.php?pid=225877#p225877

с этим высказыванием вы согласны?

весьма содержательное
один контр-пример может разрушить всю теорию

 

rei3er

млин, я в ужасе) ====>> ты просто взял и забил на всё, что здесь говорилось)) ======>> примеры давай невозможного))

 

sidt, lidt, lgdt, lldt, sgdt, wrmsr, rdmsr, ltr, str, lmsw, smsw, wbinvd и т. д
давай, реализуй это на ЯВУ
без ассемблерных вставок
и чтобы каждая реализованная функция была кроссплатформенной, т. е предоставляла одинаковый интерфейс для всех архитектур