OSDev

для всех
Текущее время: 13 ноя 2018, 23:01

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 8 ] 
Автор Сообщение
СообщениеДобавлено: 23 июн 2008, 22:08 

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 24 июн 2008, 02:01 
Аватара пользователя

Зарегистрирован: 16 май 2007, 23:46
Сообщения: 1092
Чем тебе ЯВУ не угодил?
Цитата:
Если использовать в качестве языка написания большей части оси и приложений специальный байткод более низкоуровневый чем C но немного более высокоуровневый чем ассемблер. Для приведение в рабочее состояние он должен будет компилироваться в код наиболее подходящий для рабочей машины, и (скорее всего) в таком состоянии и хранится в файловой системе (чтоб каждый раз не компилировать).
С реальным ассемблером конечно по скорости ничто не сравнится, но если удастся добится скорости до 1.5-2.5 раз от скорости чистого асма то это уже вполне прилично

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


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

Цитата:
2) Использовать принцип форта со стековыми аргументами ( в этом случае работа с регистрами целиком ложится на компилятор.

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 24 июн 2008, 15:59 

Зарегистрирован: 07 апр 2008, 21:33
Сообщения: 3
Собственно, такой вопрос уже решен. Как вариант - Java, Parrot.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 26 июн 2008, 19:00 

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 27 июн 2008, 13:23 

Зарегистрирован: 31 май 2008, 22:02
Сообщения: 4
to Dragon

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 27 июн 2008, 16:37 

Зарегистрирован: 31 май 2008, 22:02
Сообщения: 4
zenixan
Цитата:
Собственно, такой вопрос уже решен. Как вариант - Java, Parrot.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 27 июн 2008, 17:25 

Зарегистрирован: 31 май 2008, 22:02
Сообщения: 4
Pavia
Цитата:
А что есть стандартный ассемблер?

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

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

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 29 июн 2008, 21:51 

Зарегистрирован: 04 ноя 2007, 14:48
Сообщения: 113
2 Alver:

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

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


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 8 ] 

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 5


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
Создано на основе phpBB® Forum Software © phpBB Group
Русская поддержка phpBB