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

тот, который получается после трансляции кода на ассемблере, но перед линковкой
W4FhLF
дело говоришь   
Только как ты вывод то на С делал? Без ассемблера тут тоже никак (все таки тут надо либо через int 10h или через порты напрямую)

Как всё сделано в моей Python-os(гипотетической):

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

всё. а вы говорите....

Это сообщение отредактировал(а) Daevaorn - 5.1.2007, 15:16

1) взял нахамил    - у меня правило == ставить только плюсы...
читай подпись у smartov
2) можно на ты
3) меня убивает ситуация: за 40 страниц я никого не оскорбил, не кричал "дельфи маздай", не называл дельфистов "криворукими придурками" (я сам на дельфих писал) и не тебе...
4) я не упирась - хочешь считать что ВООБЩЕ нельзя написать ОС (блин даже две-три строчки которые будут вызывать сишный код, а тот в свою очередь асемблер, а скомпилить можно - нужно желание - сишный код, который вызывает питоновский) - пожалуйста, думай так - я по этому поводу переживать не буду.


1) если буду заниматься этим извратом - то к тебе обязательно обращусь (уже записал)
2) W4FhLF, есть одна проблема - ты не внимательно читаешь мои посты  я неоднократно писал что питон хорошо совместим c Си.
3) я сказал что есть ФОРУМЧАНИН который пишет ОС на питоне (многие моменты организованы на питоне). я сам скептически отношусь к этому мероприятию, - зачем писать то что уже есть и бесплатное? Но это его дело. Но за это время я ниразу не сказал что ОС можно написать использую ТОЛЬКО питон и даже часто писал что считаю что если это и возможно (? во что я не верю), то будет такой изврат.
4) ОС на питоне может быть просто обёрткой Си и asm

Добавлено @ 15:05 
Daevaorn, дай, пожалуйста, ссылку - самому стало интересно. можно и в личку.

Daevaorn, 
вот, другое дело, уже пример есть

только на С не получится
да и на С + assembler тоже: слишком много тут возни с адресами и прочими пакостями

это будет raw binary code? Иначе нужен планировщик (который у тебя на Python   )

на С не напишешь
только С + assembler

Кстати, смотри
Допустим у тебя есть интерпретатор и он выполняет скрипты
Через APIC процессору пришел сигнал о прерывании. Он моментально переходит на обработчик прерывания, но для того, чтобы начать интерпретировать код обработчика ему нужен интерпретатор, а интерпретатора то нет (EIP то изменился при переходе на обработчик через шлюз)

Конечно. В видеопорт и писал. 


pythonwin, да ладно, не держи зла на меня старик Просто в какой-то момент вы переступили грань в своих утверждениях ;)

Я имел ввиду "уже с применением С"

да

да, который ищет зарегестрированный скрипт на это прерывание и его запускает

Кстати, опять по поводу pythonOS
Daevaorn
у тебя же не получится вообще использовать защищенный режим потому как:
Твой интерпретатор работает на ring0 (иначе быть не может, потому как он интерпретирует ОС) & любая пользовательская программа им же интерпретируется => любая пользовательская программа работает на ring0 со всеми последствиями

Добавлено @ 15:29 

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

кроме того, никакой памяти не хватит для работы такой ОС:
при любом изменении EIP мы теряем интерпретатор, значит в целевом коде, на который мы осуществляем прыжок, должен быть вызов интерпретатора, чтобы этот код интерпретировать. В свою очередь в этом коде тоже есть команды перехода => опять потеря интерпретатора, опять его вызов и т. д. Стек мгновенно переполнится

не понял. почему мы здесь теряем интерпретатор?

Хе-хе. Пользовательская программа интерпретируется скриптом, т.е. интерпретатор в интерпретаторе получется. А значит я сам могу контролировать пользовательское ПО, поэтому не парюсь по поводу встроенной защиты процессора, а делаю её сам. Да и потом, кто тебе сказал, что у меня под x86 ОС?

А что мне IP. Интерпретатор то из памяти никуда не делся, а значит я смогу его запустить.

Интерпретатор - программа. Программа набор команд. В данной ОС процессор выполняет команды, которые соответствуют коду интерпретатора, т. е:
____________ EIP (адрес 1-ой команды интерпретатора)
____________ EIP + A1 (адрес 2-ой команды интерпретатора)
............................
____________ EIP + An (адрес n-ой команды интерпретатора)
Допустим есть скрипт который интерпретируется интерпретатором   
Т. е процессор выполняет последовательно команды 1, 2, 3, ... , k
на k-ой команде интерпретатора какая-то команда скрипта идентифицируется. Пусть это будет вызов функции

Здесь должна быть команда call на "адрес 1-ой команды интерпретатора" и все начнется сначала: идентификация команд функции F(). А если учитывать, что функция использует стек + сам интерпретатор исполь зует стек + много вызовов функций и переходов => стек порвется мгновенно
По поводу потери интерпретатора, не так выразился  

Добавлено @ 16:12 

неа
не получится   

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

Обоснуй.

Добавлено @ 16:33 
Да, и вообще где модератор, пусть разделит темы.

на чем будешь писать код, который передает управление интерпретатору с целью поиска обработчика (кстати ужасно медленно будет)?

кажись начинаю догонять, что теоретически из этого что-то может выйти   

Господа системщики, просветите, пожалуйста, как обстоят дела с boot sequence и всем остальным на EFI. В том, что касается доли ассемблера в коде ОС. По идее, потребность в нём должна снизиться…

А кто сказал, что прикладной код написан на питоне? Он может быть написан хоть на ассембере.
Системный интерпретатор питона выполняет только код ОС, к прикладным программам он не относится.