Центр информации по операционным системам: Форумы / Низкоуровневое программирование / Ответ Javе и Flash'у

Центр информации по операционным системам :: Форумы :: Программирование :: Низкоуровневое программирование		<< Предыдущая тема \| Следующая тема >>
Ответ Javе и Flash'у

Переход на страницу 1 2 [3] 4 5 6 7
Модераторы: Roman I Khimov, Wanderer, Dron

Автор Добавил

NightRadio

Вторник 30.09.2008 12:10

ID пользователя #1102

Зарегистрирован: Четверг 11.09.2008 14:48
Сообщений: 23

Ага, спасибо. Я тоже пока к 3му варианту склоняюсь.
Про ARM я читал - довольно интересно придумано. Но не уверен, что так же стоит делать в байт-коде.

Наверх

Dron

Вторник 30.09.2008 13:44

ID пользователя #13

Зарегистрирован: Понедельник 05.07.2004 11:16
Местонахождение: Москва
Сообщений: 651

В джаве тоже сделано не так как в ARM.

смысл в том, что высокоуровневый эмулируемый ассемблер может быть вообще не регистровый и не стековый, а полноценно объектный (java почти так), Это конечно усложнит интерпретатор байткода, но в тоже время предоставит большой простор для оптимизации. И что самое главное минимизирует размер приложений.

Хотя все это не те цели к которым следует стремиться. Главное не надо пытаться копировать процессор. нафига? Если уж взялся изобретать велосипеды - надо изобретать свой.

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

Андрей Валяев

Наверх

ossadchy

Суббота 04.10.2008 18:14

ID пользователя #941

Зарегистрирован: Среда 10.10.2007 22:55
Местонахождение: Украина, Николаевская обл., г. Первомайск
Сообщений: 181

NightRadio написал(а) ...

Да, байт-код Java достаточно компактный. Но хочется еще проще и без стековой модели.

Если простота -- самоцель, то Smalltak или Self -- вот предельно простые VM.

NightRadio написал(а) ...

Кроме того, хорошенько подумав, я решил, что изначально проект будет без поддержки многозадачности. Для мультимедийных задач вполне хватит. Работали же нормально в DOS и PalmOS

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

Многозадачность, ну как минимум, многопоточность -- это уже стандарт де-факто, без этого -- ну никуда... никто даж не рассмотрит такую ОС/VM как серьезную вещь..

NightRadio написал(а) ...

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

Ну для начала -- не совсем чётко(пока) сформулированы цели/идеи проекта. "Подключатся" можно к проекту который, как минимум, сформировался идеологически и имеет четко поставленные цели...

NightRadio написал(а) ...

Есть конкретный вопрос.
Как в байт-коде лучше реализовать команды условных переходов.
Я вижу такие варианты:

1)
CMP r1,r2 //Сравнили два регистра. Результат - флаги после сравнения (как в обычных железных процах)
Jxx ptr //Условный переход в зависимости от флагов

2)
CMPxx r1,r2 //Сравнение, где xx - тип сравнения (больше, меньше, равно). Результат - ОДИН флаг сранения (да/нет)
JMP(если флаг установлен) ptr
JMP(если флаг не установлен) ptr

3)
Jxx r1,r2,ptr //Условный переход со сравнением.
Примеры:
если r1 > r2, переход на ptr
если r1 < r2, переход на ptr

Ваши предложения?

Для начала решите какая архитектура процессора -- какие флаги, сколько флагов, какие регистры, сколько регистров, какая модель доступа к памяти.. в конце-концов -- CISC или RISC это машина... а потом уже можно обсуждать набор комманд... а регистровые VM все же сложней нежели стековые, при чем в 2х моментах:
1. в реализации
2. на этапе компиляции сложней генерировать код.

А вообще, сама идея "ответ JAVA и FALSH"(хотя сюда же и .NET) -- мне весьма близка. Т.к. пока opensource будет перереализовывать комерческие продукты, свободные клоны оных всегда будут где-то сзади... Это не есть верный подход, т.к. ИМХО давно пора уже реализовать свою платформу(язык, виртуальная машина и пр.) на которой бы и велась дальнейшая разработка ВСЕГО открытого софта(в идеале).
Вот открыл тему.

[ Редактирование Понедельник 06.10.2008 17:34 ]

Наверх

NightRadio

Суббота 04.10.2008 21:17

ID пользователя #1102

Зарегистрирован: Четверг 11.09.2008 14:48
Сообщений: 23

А можно пояснить, почему регистровая модель сложнее при компиляции, нежели стековая? То есть, в случае, когда на выходе нужно получить хороший native-код, который использует в большей степени железные регистры, а не память, эмулируя стек виртуальной машины.
Сорри, остальные посты пока не коментирую, так как сейчас занят проработкой архитектуры и вообще идеологии проекта.

Наверх

ossadchy

Суббота 04.10.2008 22:39

ID пользователя #941

Зарегистрирован: Среда 10.10.2007 22:55
Местонахождение: Украина, Николаевская обл., г. Первомайск
Сообщений: 181

NightRadio написал(а) ...

А можно пояснить, почему регистровая модель сложнее при компиляции, нежели стековая? То есть, в случае, когда на выходе нужно получить хороший native-код, который использует в большей степени железные регистры, а не память, эмулируя стек виртуальной машины.
Сорри, остальные посты пока не коментирую, так как сейчас занят проработкой архитектуры и вообще идеологии проекта.

Поясняю на примере.
есть выражение


x * y / z + w

распарсили его в дерево


(+, (/,(*,x,y),z), w)

для стековой VM компиляция предстваляет собой обход дерева и генерацию примерно такой последовательности инструкций




push x

push y

multiply

push z

divide

push w

add

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




push a

push b

add

pop c

в комманды вида




add a,b,c

ну примерно вот так..

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

А еще, если интересно, можете глянуть на LLVM -- регистровая VM.

[ Редактирование Понедельник 06.10.2008 17:35 ]

Наверх

Roman I Khimov

Суббота 04.10.2008 23:12

ID пользователя #1

Зарегистрирован: Воскресенье 27.06.2004 12:37
Местонахождение: Санкт-Петербург
Сообщений: 601

ossadchy написал(а) ...

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

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

Вообще, SDE/Juice это одна из очень правильных идей была. Байт-код тянется с незапамятных времён "Паскаля", отчего ещё называется иногда "пи-кодом". Тогда чисто ради переносимости был сделан финт ушами с компиляцией к какому-то абстрактному процессору и затем исполнением из этого кода, причём, чисто последовательной интерпретацией. Но для этого и процессор виртуальный придумать надо, и компилятор в него, и, как выяснилось уже позже, оптимизировать всё это не так просто, много надо работать.

А SDE тупо берёт и пилит компилятор пополам. Большая часть их всё равно строится именно по таким принципам, с приведением любого исходника к чему-то абстрактно-синтаксически-деревянному, а потом оттуда в целевой код. И всё отлично.

Нет, надо машинками играться, кто стековыми (эти ещё хоть ближе к AST, из них проще восстанавливаться и работать с деревом), кто вообще регистровыми... Забыть про это всё уже давно пора...

Греби и улыбайся!

Наверх

ossadchy

Воскресенье 05.10.2008 00:47

ID пользователя #941

Зарегистрирован: Среда 10.10.2007 22:55
Местонахождение: Украина, Николаевская обл., г. Первомайск
Сообщений: 181

2Roman I Khimov: вот и я о том же... хотя усложнять себе жизнь -- одно из важнейших занятий человечества. и получается это на 5+.

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

[ Редактирование Понедельник 06.10.2008 17:39 ]

Наверх

Dron

Воскресенье 05.10.2008 10:33

ID пользователя #13

Зарегистрирован: Понедельник 05.07.2004 11:16
Местонахождение: Москва
Сообщений: 651

Вполне логично, что чем выше уровень программного представления, тем шире простор для оптимизаций.

Но есть много разных оптимизаций, которые стоит производить всетаки на этапе компиляции.

Андрей Валяев

Наверх

ossadchy

Воскресенье 05.10.2008 13:57

ID пользователя #941

Зарегистрирован: Среда 10.10.2007 22:55
Местонахождение: Украина, Николаевская обл., г. Первомайск
Сообщений: 181

Dron написал(а) ...

Но есть много разных оптимизаций, которые стоит производить всетаки на этапе компиляции.

А к чему-то вел?

БольшАя часть оптимизаций(распределение регистров и т.д.) ведется как раз при кодогенерации и представление в виде деревьев не отвергает это, а лишь упрощает.

Dron написал(а) ...

Вполне логично, что чем выше уровень программного представления, тем шире простор для оптимизаций.

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

[ Редактирование Понедельник 06.10.2008 17:40 ]

Наверх

NightRadio

Воскресенье 05.10.2008 15:36

ID пользователя #1102

Зарегистрирован: Четверг 11.09.2008 14:48
Сообщений: 23

Я давно знаком LLVM и являюсь его большим поклонником. Вещь действительно очень мощная и может оперировать как раз таки промежуточным уровнем - бит-кодом, который и не стековый и не регистровый, все имена в нем уникальные, т.к. он основан на SSA. Мне вообще кажется, что чисто с практической стороны LLVM - это как раз то что нужно. Быстрее и универсальнее придумать очень очень сложно.
Но лично для меня есть одно но - llvm ну слишком уж крут, слишком наворочен. И машина на нем займет мегабайт эдак 10.. Насколько быстро она будет интерпретировать и компилировать - тот еще вопрос... Я поклонник более компактных вещей.
Это раз.
А еще по поводу виртуальных машин. Почему же в основе Google Andriod виртуальная машина Java, и не обычная, а видоизмененная для поддержки регистр-ориентированного байт-кода?

Наверх

Переход на страницу 1 2 [3] 4 5 6 7
Перейти: Наверх