Board.KolibriOS.org

Mario wrote:А кто говорит об отказе от x86?

art_zh, да вроде никто не собирается удалять бинарики и исходники текущей версии КоОС со всех носителей информации мира, или запрещать их использовать

одно дело - хранить открытые архивы старых сорцев.

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

art_zh
Ты, уж извини, но никто из разработчиков вроде никаких договорных обязательств не подписывал - чисто свободное творчество, в свободное время и при наличии желания и доброй воли. По крайней мере могу говорить за себя.
К тому же техника не месте не стоит и 32-х разрядные процессора x86 сходят с арены потихоньку. Да, пока серьезного использования EM64T не наблюдается, но это временное явление. И вообще честно говоря я не понимаю нервной реакции на желание расширить область применения. Всего лишь желание, исключительно мое в частности, и я уже давно в проекте не ведущий разработчик. Безумная идея тоже написал не просто так.

Я конечно человек пока не внесший не байта в ситему, но в принципе понимающего немного ARM, уверен, что в любом случае x86 останется уже не такой как сейчас. Потому и предлагаю реализовать минимальную виртуальную машину, чтобы портабельность была не против старого кода, но и способствовала развитию. Мне КоОС нравиться.

Запускал же кто-то на iPhone на bochs - так bochs - это унверсальный эмулятор, а можно сделать максимально оптимизированный под одну платформу (пока x86) минимальную виртуальную машину (как NanoVM) под x86, и потихоньку переносить безболезненно код в платформонезависмый асм. А потом ту же виртуалку портировать под другие платформы.

ИМХО конечно, но безболезненный путь

Сразу говорю - порт на арм обеспечу. в x86 не силен

Mario wrote:art_zhИ вообще честно говоря я не понимаю нервной реакции на желание расширить область применения. Всего лишь желание, исключительно мое в частности, и я уже давно в проекте не ведущий разработчик. Безумная идея тоже написал не просто так.

По-моему, нормальная реакция - спокойный и корректный обмен мнениями на заданную тему.
: хотя эмоции сегодня конечно переполняют: http://philodox.livejournal.com/156217.html- у меня там родители

Просто если на старом ядре уже все поставили крест, то нафиг тогда париться с Вики?
Подождем пока появится Система-В-Которой-Всё-Сразу-Сделано-По-Уму...

art_zh wrote: : хотя эмоции сегодня конечно переполняют: http://philodox.livejournal.com/156217.html- у меня там родители
Просто если на старом ядре уже все поставили крест, то нафиг тогда париться с Вики?
Подождем пока появится Система-В-Которой-Всё-Сразу-Сделано-По-Уму...

1. Не пори горячку. Я к примеру когда "всеахуетькакплохо" стараюсь в сеть не вылазить. Все с твоими родственниками будет хорошо.
2. Опять поспешные выводы спровоцированные нервным состоянием.

XVilka
Это хорошо, что есть желание и навыки, а то у нас обычно недавно-пришедшие любят только разглагольствовать, а как до дела - так никак.

Mario wrote: 1. Не пори горячку. Я к примеру когда "всеахуетькакплохо" стараюсь в сеть не вылазить. Все с твоими родственниками будет хорошо.
2. Опять поспешные выводы спровоцированные нервным состоянием.

н-да,корректного обмена мнениями не вышло .

XVilka: "Запускал же кто-то на iPhone на bochs"
-насколько мне известно, это не удалось, впрочем, каку и у меня на Nokia n900.

Отношения Легиона и Колибри, в очередной раз обсасывается портируемость и "илитарность" (кто бы сомневался - Илита хуле).
http://2-ch.ru/s/res/208531.html

Смотря до какой степени переносимость делать?
Как тут предлагали, можно вплоть до VM, тогда приложение вообще от архитектуры зависеть не будет, например реализовано в android. Но быстродействие снижается в данном случае.

Если просто на уровне приложений, то можно например разнести системные функции по библиотекам, которые внутри уже ссылаются на mcall (который сейчас выполняет int 0x40). Необходимые библиотеки подключать к приложению на этапе запуска, как например сделано в винде, в виде таблицы IAT. Обработчик событий тоже вынести в библиотеку, и обрабатывать события оконной системы например внутри библиотеки (приложению же незачем знать что система делает с контроллами). Передачу аргументов можно оставить на уровне регистров, в C/C++ есть же описание для функций fastcall указывающий передавать в регистрах.

На уровне ядра, конечно хорошо бы сделать HAL, что бы по минимуму зависеть от железа. Например в том же Windows Mobile есть низкоуровневые драйвера, ядро немного заточенное под данный аппарат, а все остально уже аппаратно независимое, в том числе системные библиотеки.


P.S. Добавлю немного:
Боюсь асм код привести к яву автоматическими средствами довольно сложная задачка. Взять хотя бы тот же Hex-Rays плагин от IDA, даже он не выдает вменяемого C кода. Так что пока приложений мало, проще переписать их вручную.

Технически, конечно, можно сделать компилятор, переводящий программу с одного языка ассемблера на другой, но, ИМХО, смысла в этом абсолютно никакого нет -- хотя бы потому, что теряются все достоинства кода на асме (компактность и высокая скорость по сравнению с тем, что дают на выходе быдлокомпиляторы, да и не с быдло-, а с супер-пупер-мега-оптимизирующими тягаться вполне реально). Так что лично мне думается, что прикладные программы всё ж надо было бы писать на ЯВУ. Ну а вручную переписать ядро на другую архитектуру -- отнюдь не мегатруд по объёму из-за сравнительно небольшого объёма этого самого ядра, а также из-за того, что изрядная часть тамошнего кода всё равно завязана на аппаратуру, а значит, и на ЯВУ ручных переделок хватило бы. А в дальнейшем -- просто поддерживать параллельно несколько веток ядра под разные архитектуры, но идентичных на "логическом" уровне (с точки зрения прикладного программиста: одинаковые системные вызовы и всё такое). Тем более что стремиться к всеохватности а-ля Линух никакого смысла нет, результатом будет система, неэффективная абсолютно на любой платформе.

SII
Гениально!
Ты час другими словами рассказал мой же первый пост этой темы.

З.Ы. Вообще последнее время кажется, что люди не вчитываются в посты друг-друга. Выхватывают пару знакомых слов и понеслось! А потом начинается мордобой в 99% случаев.

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

Тут прихожу я и решаю откопать полузасыпанную тушку темы...

Есть такая тема: http://ru.wikipedia.org/wiki/Low_Level_Virtual_Machine
Оригинальный ресурс http://llvm.org/
Подробности http://llvm.org/docs/LangRef.html

Mario_r4 wrote:Тут прихожу я и решаю откопать полузасыпанную тушку темы...

Есть такая тема: http://ru.wikipedia.org/wiki/Low_Level_Virtual_Machine
Оригинальный ресурс http://llvm.org/
Подробности http://llvm.org/docs/LangRef.html

под LLVM есть язык Steker близкий к "виртуальным" процессорам и Forth процессорно-независимой вычислительной модели

P.S. Форт наиболее простой процессорно-независимый язык, но как грамотно его перекладывать, например, в регистровые операции
нет полного понимания (или макро-оптимизатор как в SPF4 Форт системке или придумывать своё или "изучать" как это делается в коммерческих Форт системах)

Kopa
Нужен компилятор любого языка в байткод LLVM, а то Fort не все захотят осваивать.