Linux or Windows?

rei3er

одно могу посоветовать - перечитай мои топики, ибо твой вопрос не нов в этой теме)

 

UbIvItS
я ответил на вопрос?

исходя из этого

если да, вопрос закрыт, если нет - жду пояснений

 

UbIvItS
почитай во это
http://ru.wikipedia.org/wiki/ЯВУ

 

10 страниц уже =) гы

 

rei3er
ладно, я терпеливый)
итак, можно сделать на яву:
операции ариф./лог./ветвления (усл./безусл.)/IO/IRQ???
яляется ли этот перечень наиболее полным функционалом проца???
--------------
на все вопросы ответ - да.

 

UbIvItS
давай определимся
что ты подразумеваешь под

использовать ассемблерные вставки в коде универсальных функций (с универсальной для всех архитектур сигнатурой) или использовать только языковые конструкции в коде все тех же универсальных функций?

 

UbIvItS

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

 

rei3er
ф-ции везде будут иметь один и тот же вид: LowLevelIo(number_port, size_data, data), IRQ(number_irq, number_port, handler) а вот реализации фунок под каждый проц идут на его родимом асме, все остальные параметры, не входящие в заголовоки фунок, но имеющиеся на конкретном проце, будут выставляться компилем на основе надобности экономии времени или памяти.

 

reiser, песали:

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

Есть конечно исключения, как например вышеупомянутый, мною кросплатформеный дров KQEMU, код которого являет беспрецендентный пример отваги и доблести в нулевом кольце защиты:

Код (Text):

1.         /* switch address space */
2.         mov KQEMU_STATE_kernel_cr3(%rdi), %rax
3.         mov KQEMU_STATE_monitor_data_kaddr(%rdi), %rdi
4.         mov %rax, %cr3
5.         mov %rcx, %cr4
6.        
7.         lidt KQEMU_STATE_kernel_idt(%rdi)
8.         lgdt KQEMU_STATE_kernel_gdt(%rdi)
9.         lldt KQEMU_STATE_kernel_ldt_sel(%rdi)
10.  
11.         mov KQEMU_STATE_kernel_esp(%rdi), %rsp
12.  
13.         /* change CS */
14.         movzwq KQEMU_STATE_kernel_cs_sel(%rdi), %rax
15.         push %rax
16.         lea ASM_NAME(monitor2kernel_jmp_offset)(%rip), %rax
17.         push %rax
18.         lretq

ради благой цели достижения быстродействия в эмуляции машинных команд i386/64 процессоров, в обход стандартных средств венды или линупса...

reiser, спрашивали:

цитато, by SII

С учетом вышесказаного мною, и приведеного примера кода, трудно не согласиться с этим фактом...

Однако, господин хорошый, вы хоть сами-то понимаете каким уровнем проффесионализма нужно обладать, чтоб РУЛИть всей этой хренью

а???
этож включает обширные знания как аппаратных особеностей платформ, програмных систем, и тонких особеностей компиляторов...

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


Ну так вот, сорцы дрова ко всему прочему препроцесились через GCC,
(по типу того паровоза который ехалъ ф копенгаген через ротердам, а приехал в газенваген)

Код (Text):

1. #define SEG_EXCEPTION(label) \
2.     .section "seg_ex_table", "a" ; \

и из за данного определения секций НЕ компилился Win32 портом, этого компилера (каких тока версий из MinGW не перепробывал), зато на ура кушался в Linux
помогли хаки кой какие.. Однако потом обламал LD не осиливший скрипт

Код (Text):

1. ENTRY(_start)
2. SECTIONS
3. {
4.   . = 0xf0000000;
5.   .text      : { *(.text) }
6.   .rodata    : { *(.rodata) }
7.   . = ALIGN(4);
8.   __start_seg_ex_table = . ;
9.   seg_ex_table : { *(seg_ex_table) }
10.   __stop_seg_ex_table = . ;
11.   .data    : { *(.data) }
12.   .plt      : { *(.plt) }
13.   .got           : { *(.got.plt) *(.got) }
14.   .bss       : {
15.      *(.bss)
16.       *(COMMON)
17.   }  
18.   . = ALIGN(4096);
19.   _end = . ;
20. }

Видимо аффтары PE-шки kqemy.sys юзали хорошо пропатченый инструментарий...

А вообще, ручная ASM выделка, более востребована для программирования убогих 8-битных микроконтроллеров, с килобайтом на борту, и мегагерцом частотой, для которых нема боле-менее приличных HLL компиляторов.

И то если овчина- стоит того, поскольку даже в ОСях древних мобильных ARM-based уст-вах, не считались ни с байтом ни с быстродействием, клепая дешовые тормозные поделия с J2ME (под нужды программирующего потребителя...)

 

bogaga

и что?
поэтому можно эту специфику вычеркнуть?

господин хороший
ничего сложного здесь нет
(говорю применительно к себе, хотя я не считаю себя каким-то большим профессионалом)

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

что вы мне пытаетесь доказать?
что большинство кода пишется на С? так это я и без вас знаю
вопрос был в том, что многие вещи на ЯВУ не реализуются в принципе

UbIvItS

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

 

позвольте, увожаемый мосье reiser, а с чего это, Вы вдруг решили что нижеприведенной вами моей цитаты насчет овчины и выделки, была с моей стороны попыткой чего то там доказать, да еще именно Вам?

Это опять ошибка с Вашей стороны, я просто высказал свое наблюдение по вопросам асмЪ программирования, только и всего..

 

UbIvItS

Ещё раз: есть архитектуры, где нет никаких портов или ячеек памяти для доступа к устройствам. И устройства получают сразу целые программы, которые они должны выполнять, без всяких установок-сбросов отдельных регистров или их битов.

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

 

Скоро по количеству страниц "Улыбнитесь" догонит.
Замечу что не совсем правильно было сравнивать asm и ЯВУ основываясь на преимуществах asm'а - четкая заточенность под платформу и ее команды, с таким-же успехом можно сказать что на asm нельзя написать классовую программу, что конечно возможно, но равносильно использованию тех же asm вставок в ЯВУ.

 

GPU например )

 

t00x

Ну, к GPU, наверное, обращение от ЦП идёт всё же через регистры. Ну а в приведённом мной несколькими постами выше примере запуска операции ввода-вывода никаких регистров нет в принципе: программа для устройства формируется центральным процессором в оперативной памяти, адрес начала этой программы заносится в строго определённую ячейку физического ОЗУ, после чего ЦП выполняет специальную инструкцию начала ввода-вывода. Всё, его роль выполнена, всё остальное делает оборудование, связанное с вводом-выводом: считывает из ОЗУ одну за другой команды, адресованные внешнему устройству; ожидает, пока устройство их выполнит; в зависимости от результатов после каждой команды может прекратить выполнение программы, совершить переход или продолжить выполнение и т.п. В общем, никакими программно адресуемыми портами ввода-вывода или их аналогами здесь и не пахнет.

 

SII

GPU поддерживают аналогичный механизм, называемый "проецируемые в память файлы" или же "регистровые файлы".

P.S. попонятней написал.

 

t00x

Спасибо, буду знать. Никогда раньше с ГП напрямую не работал, да и вообще особо не интересовался. Век живи -- век учись. И дураком помрёшь )

 

rei3er

а какую роль играют эти параметры?? - оптимизация =====>> и я уже говорил:"параметры выставляет компиль"
>>>кроме того, что делать с примером SII?
в/в переферии и в/в центрального/ых проца/ев - это разные вещи, а мы говорим о первом моменте.
ещё: я кучу раз повторял, что портирование рассматривается на процы с равным уровнем функционала.
ты постоянно говоришь о проблеммах реализации асм команд, а вот вопрс тебе - какой смысл пытаться портировать эти команды))??..? неужели не чувствуется разницы между понятием функции процессора (его функционал) и понятием реализация функции) =========>> кол-во реализаций уйма, а вот функционал максимум состоит из того, что я перечислил + возможности отладки (забыл я об этом как-то))

 

UbIvItS

С равным уровнем функционала -- да, номер пройдёт. Только вот таких процессоров маловато будет. Точней, если взять некий функциональный мниимум, то их будет большинство, однако при попытке его расширить процы сразу начнут "отваливаться" один за другим. Так что полной переносимости системного ПО путём переписывания лишь нескольких библиотечных функций добиться не удастся в любом случае.

 

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