OSDev

Мне вот стало интересно чисто теоретически поразмышлять над следующими вопросами:
Сейчас 32-х битные процы сдают позиции 64-х битным, проги и оси написанные на асме под 32-х битные процы, хотя и работают на новых процах, но уже не в полную силу. Есть конечно C и другие ЯВУ, но думаю найдется немало тех, кому не очень хочется писать под них. Поэтому мне любопытна несколько другая идея.
Если использовать в качестве языка написания большей части оси и приложений специальный байткод более низкоуровневый чем C но немного более высокоуровневый чем ассемблер. Для приведение в рабочее состояние он должен будет компилироваться в код наиболее подходящий для рабочей машины, и (скорее всего) в таком состоянии и хранится в файловой системе (чтоб каждый раз не компилировать).
С реальным ассемблером конечно по скорости ничто не сравнится, но если удастся добится скорости до 1.5-2.5 раз от скорости чистого асма то это уже вполне прилично.
Вторым вопросом является структура байткода. Поскольку она планируется более низкоуровневая чем C, то должна предоставлять большие возможности ручной оптимизации, большую лаконичность и детальность команд, при этом оставаясь достаточно кроссплатформенной.
Тут в принципе видно два варианта:
1) Использование принципа стандартного асма с виртуальными командами и регистрами.
2) Использовать принцип форта со стековыми аргументами ( в этом случае работа с регистрами целиком ложится на компилятор.
Мне нравится структура описания параметров в форте, но думаю для байткода с оптимизацией по скорости ее придется сильно переработать.
Впрочем пока это все только размышления. Хочется послушать мнение других. ;)

Чем тебе ЯВУ не угодил?

Тежи яица вид сбоку.SII Уже по этому поводу писал. Можешь его посты на Wasm.ru почитать.


А что есть стандартный ассемблер? А какже оптимизация ввиде SSE? И прочее.


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

Как по мне ЯВУ достаточно. А что касается переносимости кода. То это заслуга програмиста.

Собственно, такой вопрос уже решен. Как вариант - Java, Parrot.

Я бы использовал компактное древовидное представление кода, это как раз получается нечто, более низкоуровневое, чем яву, но намного более высокоуровневое, чем асм. Если хорошо подумать, то можно выделить примитивы для такого "ассемблера", основываясь например на концепции ООП (объекты, операции). А уже исполнение зависит от конкретной ВМ, будь то интерпретация, компиляция, или ещё что то...

to Dragon

Боюсь если в байткод пытаться впихнуть ООП, то о низкоуровневости (читай производительности) придется забыть.
Думаю допустимы лишь некоторые элементарные средства инкапсуляции процедур.

zenixan

К стыду своему должен признаться что инфы по этим кодам у меня практически нет.
По байткоду Java я пробовал както раньше поискать в гугле - попадалось на английском но я в нем не очень. Я прочел гдето что код вроде бы использует стековую форму аргументов, но почемуто мне кажется что код сильно привязан к обьектной структуре языка. (Возможно я не прав ? - Увы недостаток информации. Если кто знает ссылочку на внятное описание байткода Java на русском, киньте плиз. )
Parrot насколько я понял являет пример 1-го типа байткода т.е. использует принцип asmа с виртуальными регистрами (личное ИМХО виртуальные регистры хороши для виртуальной машины, но не очень для компилятора из байткода в натив)
Кроме того оба этих формата изначально предназначены для создания кроссплатформенных приложений, работающих внутри виртуальных машин (хотя вообще говоря на жабу есть компиляторы) и как то не предполагались для написания самих осей. Меня же интересует как раз вариант с осью.

Pavia

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

Логически это дело как раз для компилятора из байткода в натив, ведь SSE и прочее это жесткая привязка к платформе. И на при использовании регистровой модели байткода, на мой взгляд здесь будут большие затруднения чем со стековой моделью.

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

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

2 Alver:

Я думаю стоит более адекватно воспринимать ООП. Это же не фрэймворки, а только концепция. Почему бы концепцию не положить в основу создания чего то нового? (как ты говоришь, вариант форта не катит, зато можно сделать оглядываясь на него). Если надо сделать именно ассемблер/байткод... просто абстрагировать регистры, память, и порты? А зачем? Вроде есть уже... или я ошибаюсь? Как по мне, если что то новое делать, то оно должно содержать какуюто идею! Ведь никто же ещё ООП-асм не сделал =) А ещё как вариант можно посмотреть П-код для КОЛа. Может это ты ищешь? http://kolmck.net/ - там раздел загрузки, подраздел инструменты, почти в самом низу.

Ещё я хотел уточнить, что имеется ввиду, что байткод создаётся для написания ОСей? Для написания ядра? Драйверов? Приложений? каких конкретно компонент? Я могу просмотреть выгоду от байткода в ядре и дровах с большо-о-ой натяжкой =)