PDA

Просмотр полной версии : на Java для ZX



Raydac
08.01.2012, 01:35
not a short message

Vitamin
08.01.2012, 02:16
Уже было
http://zx.pk.ru/showthread.php?t=1830

GriV
08.01.2012, 09:47
Виталик, ты чего как отрезал?

raydac> А для чего вам ява-машина нужна?

mastermind
08.01.2012, 10:35
выходит что потенциально можно JVM юзать как промежуточный язык для последующей трансляции даже в код для 8ми битных процов
Если есть желание что-то такое делать, ИМХО лучше смотреть в сторону LLVM (см. http://llvm.org/ ).
Там одно время был бэкэнд для PIC16, но автор перестал его поддерживать и в новых версиях его нет (из git-репозитария, естественно, все равно можно вытащить и посмотреть на него, см. бренч pic16 там).

GriV
08.01.2012, 11:42
Это интересно. Т.е. фактически компилятор?

jerri
08.01.2012, 11:52
Raydac, а транслирует в текстовый исходник или в готовый машинный код?

andreil
08.01.2012, 12:05
jerri, Вроде как было сказано, что

тренслирует в командны z80 найденные инструкции, никакой jvm там нету

jerri
08.01.2012, 12:48
Raydac, а отдельно текст можно посмотреть из того верхнего примера

---------- Post added at 12:48 ---------- Previous post was at 12:37 ----------

я имею ввиду полученный исходник

jerri
08.01.2012, 12:56
ужос
все через жо.. стек
это вот так работает джава? неудивительно что она везде тормозит

jerri
08.01.2012, 13:02
а та которая на портативных устройствах?
телефоны и тп?

mastermind
08.01.2012, 14:53
Еще раз хочу указать на существование LLVM (т.к. он идеально для данной задачи подходит).
Почитайте http://llvm.org/Features.html
Все что нужно, грубо говоря - сделать backend для Z80 (чтоб оно знало как со своего внутреннего "машинного кода" (IR - "internal representation") преобразовывать код в код Z80).
В результате получится куча готовых оптимизирующих компиляторов (C, C++, Obj.C, Java и т.д.) и прочих инструментов. Часть проходов оптимизации производится до преобразования в конечный машинный код, на уровне внутреннего "машинного кода" но с учетом характеристик конечной платформы, типа числа регистров, разрядности, доступных операций и т.д. Плюс можно дописать свои, специфичные для платформы.

---------- Post added at 12:53 ---------- Previous post was at 12:43 ----------

К слову о применимости LLVM для компиляции высокоуровнего кода во что угодно: backend компилирующий в javascript: https://github.com/kripken/emscripten/wiki (там есть онлайн демки).
Т.е. берется C, C++ и прочий код, на выходе получается javascript.
То же можно сделать и для Z80, но пока никто не сделал соответствующего backend-a. Понятное дело, органиченность объема оперативки Speccy нужно учитывать, но тем не менее. Да и переключение страниц по идее можно вполне прозрачно реализовать. (типа long jumps/calls)

GriV
08.01.2012, 22:01
Друзья мои! Напоминаю что название топика "на Java для ZX"! Будьте бдительны! не дайте себе завлечь в обсуждение не по теме! :)

---------- Post added at 21:01 ---------- Previous post was at 20:52 ----------


jvm везде одинаковая, но как я и сказал google для андроида юзает не jvm а dalvik и там уже не стековая
p.s.
в принципе про тормоза явы я бы не сказал, jvm байт код и на писишке юзается как промежуточный язык и hotspot оракловый на лету компилит его (с учетом особенностей платформы) в машинный код и более того, производит постоянный мониторинг количества обращений к тем или иным участкам и на лету их оптимизирует, так что это в какой то мере круче чем на С++ писать со статической компиляцией
У нас была система Lotus Domino, она зижделась на Java, ну очень уж тугая была система. Для сотиков Java прижилась потому что позволяла создать аппаратно независимое ПО (хотя есть и обратное мнение, опять же что с чем сравнивать). А касательно С++ - дотнет компилирует на старте приложения, и скорость говорят приличная и якобы аппаратная независимость и адаптивность.

alone
09.01.2012, 04:50
А касательно С++ - дотнет компилирует на старте приложения, и скорость говорят приличная и якобы аппаратная независимость и адаптивность.
Одна беда - гигабайт библиотек, которые ещё и обновлять надо (а при обновлении иногда вся винда слетает).
Идею J2ME на ZX поддерживаю. Хотя программировать под него не умею. Зато видел кучу игр :)

megabyte
09.01.2012, 21:31
У нас была система Lotus Domino, она зижделась на Java, ну очень уж тугая была система.JVM давно является JIT-системой.

А с Lotus Domino, как исконно IBM'овский продукт не может не тормозить. По долгу службы приходится очень много возиться с IBM/WebSphere и IBM-овскими j2ee-продуктами. Пишется все это дело индусами без каких либо оптимизаций.

Сорри за оффтоп.

---------- Post added at 20:31 ---------- Previous post was at 20:30 ----------

А вообще не плохо было бы для Спектрума иметь нативный транслятор и текстовый редактор с подсветкой синтаксиса :)

megabyte
09.01.2012, 22:52
вот то то и оно, что юзание явы как p-code позволяет заюзать всю её инфраструктуру от систем разработки с халявными и вкусными IDE до систем continous integration и дебаггеровТут надо реальнее смотреть на ситуацию. Eclipse на Спектруме никогда не запустится. А какое-то приложеньице для TR-DOS было бы приятно иметь даже с эстетической точки зрения: разрабатывать на Java на реале - такого еще не было :)

Я вот тут подумал, для вашей JVM можно использовать страничную память на машинах с >128 Кб ОЗУ. Скомпилированные классы можно располагать по страницам памяти. Правда для этого потребуется какой-то постоянный диспетчер, хранящий информацию о классах - номере страницы, стартовом адресе, и осуществляющем переключение страниц и условный переход в тело класса.

А еще интересно, как будет реализована многопоточность :)

---------- Post added at 21:52 ---------- Previous post was at 21:39 ----------

А еще я подумал. Java - это чистейший ООП. ООП идеология "правильной" программы - это сплошные абстракции, корректное проектирование "по Макконнеллу", шаблоны проектирования и проч. Любой Спектрум-кодер увидев код типичного j2ee-проекта впал бы в депрессию за нецелевое использование процессорных тактов :)

Но это так, размышления в воздух...

bigral
10.01.2012, 03:21
Идею J2ME на ZX поддерживаю. Хотя программировать под него не умею. Зато видел кучу игр :)

Оно токо в тестах быстрое а на практике тормоз - есть на altere из 6000 le тормоз и все.
Есть надежда что GO! будет другим!

NEO SPECTRUMAN
12.02.2012, 23:27
куда кактится мир

На каждое действие есть противодействие.

Для более нового, быстрого железа всегда находятся более тугие, криворукие программисты.
В итоге всё всегда тормозит:)

bigral
19.02.2012, 03:06
впрочем обсуждая запуски большой явы, озвучивали компы с полутерабайтом оперативки... куда кактится мир

я провел опрос среди "своих" и получил результат - 50% думают что raspberry pi это тормоз 700mhz с минимальной оперативкой и там НИЧЕГО запустить НЕ УДАСТСЯ!

farewell
19.02.2012, 13:14
bigral, Ещё и ARM к тому же.

jerri
08.03.2012, 12:14
чего хоть делает то?

jerri
08.03.2012, 12:57
1753 байта же :(
он в таком объеме еще чегонибудь делать должен

jerri
08.03.2012, 13:06
у меня закрасил только 2/3 экрана
потом завис на зависалке.
полиморфизмы заценил да :)

Vitamin
13.03.2012, 15:31
есть char (unsgned 8 бит), short (signed 16 бит), byte (signed 8 бит), int (signed 16 бит) (!)
А почему char беззнаковый, а byte знаковый? Всю жизнь наоборот же было?

Oleg N. Cher
14.03.2012, 00:57
Идею J2ME на ZX поддерживаю. Хотя программировать под него не умею. Зато видел кучу игр :)
J2ME это тоже 32-битная платформа. И там тоже нету беззнаковых числовых типов. И есть сборка мусора. К тому же другие разрешения экрана, чем у Спека. Не, ну наверно можно с потугами сделать хелловорлд, но портировать игры... Всё же лучше через Java Decompiler + ручной перевод на Оберон c последующей трансляцией через Ofront в Си и компиляцию SDCC. Предложите небольшую, но интересную игру, чтобы опробовать такую технологию. Кстати да, будет ещё запар с графикой, музыкой, звуком, а может и ещё с кое-чем.

jerri
14.03.2012, 06:51
Oleg N. Cher, есть еще j2ce

b2m
14.03.2012, 10:34
Java Decompiler + ручной перевод на Оберон c последующей трансляцией через Ofront в Си и компиляцию SDCC.
Есть более короткий путь - просто перевод байт-кода java в код Z80. Чем, собственно, и занимается топикстартер. :)

alone
14.03.2012, 12:59
Предложите небольшую, но интересную игру, чтобы опробовать такую технологию. Кстати да, будет ещё запар с графикой, музыкой, звуком, а может и ещё с кое-чем.
Metal Slug Mobile. Я играл в одну часть, ещё под 128x176, весит 96K. А их уже 4 наклепали, уже до 320x240.
Графику можно сконвертировать в 2 цвета. Или в 16.

Oleg N. Cher
14.03.2012, 17:27
Есть более короткий путь - просто перевод байт-кода java в код Z80. Чем, собственно, и занимается топикстартер. :)

Да, но есть в этом практический смысл – эмулировать 32-битную архитектуру на 8-битной? Я думал, Вы предложите прямо с Java на C лучше писать, без Оберона как лишнего звена. :wink: Другое дело, что если там реально размер некоторых переменных можно ограничить 8 битами (со знаком или без), 16 битами (со знаком или без). Но выявить такие переменные можно только ручками.


Metal Slug Mobile.
Посмотрю.

alone
14.03.2012, 18:36
Да, но есть в этом практический смысл – эмулировать 32-битную архитектуру на 8-битной?
Она всё равно основана на 8-битных байтах. И ничего там страшного нет: http://en.wikipedia.org/wiki/Java_bytecode_instruction_listings

b2m
14.03.2012, 19:12
Но выявить такие переменные можно только ручками.
Здрасьте. Байт-код у жабы содержит абсолютно всю информацию о типах.
Если Вы внимательно читаете форум (а не только пишете), топикстартер ограничился 16-битовыми данными, и даже 32-битный int считает 16-битным :)

Oleg N. Cher
29.03.2012, 19:23
Вы как-то не так трактуете мои высказывания, b2m. Я имел ввиду вот что. Если взять готовую игру на Java (например, на J2ME/MIDP2 для мобильника) с целью портировать её для Спектрума, сможете ли сходу сказать, какие её переменные на Спеке могут занимать 1 байт, со знаком или без, а каким обязательно нужно 2, чтобы хватило разрядности, и какие из них могут быть знаковыми, а какие нет? Ничего подобного. Этой инофрмации в Java-программах нет, как и беззнаковых числовых типов. Может попытаться использовать вместо них char? Нет, для оптимального разворачивания на Z80 лучше было бы ввести такие беззнаковые типы.

alone, да, 32 бита состоит из 4-х восьмибитных байтов, а те в свою очередь из 32 битов, и что - это как-то поможет нам портировать готовую игру, которая использует везде 32-битовую арифметику, с Java на ZX?

Посмотрел скрины Metal Slug Mobile, для меня такое было бы портировать на Спек сложновато (выше моего уровня), да и проект большой. Я засматриваюсь на карточные игрушки или какие-то шарики, вот мой уровень. Если ты хотел бы заняться портом Metal Slug Mobile (на Си или на Оберон) для Спектрума, предлагаю безплатно подфорум и консультации по Оберон-технологиям (в аське или ЛС, как удобнее). Если это требуется. Всё, чем могу.

b2m, если хотите и правда меня уколоть, дескать мало читает, много пишет - а я читаю этот форум с 2007г, пишу недавно - лучше расскажите как автоматически выявить такие 32-битные переменные, которые можно безболезненно заменить на byte (8 бит без знака), short int (8 бит со знаком), word (16 бит без знака) и int (16 бит со знаком). Желательно на автомате или хотя бы полуавтомате. С учётом того, что в Java-программах очень активно используется 32-битная знаковая арифметика, даже там, где на Z80 хватило бы байта, со знаком или нет.

alone
29.03.2012, 22:39
alone, да, 32 бита состоит из 4-х восьмибитных байтов, а те в свою очередь из 32 битов, и что - это как-то поможет нам портировать готовую игру, которая использует везде 32-битовую арифметику, с Java на ZX?

32-битная арифметика на Z80 - вовсе не ракетная наука. По скорости в интерпретируемых языках что 16, что 32 - особой разницы нет.

b2m
29.03.2012, 22:57
расскажите как автоматически выявить такие 32-битные переменные, которые можно безболезненно заменить на byte (8 бит без знака), short int (8 бит со знаком), word (16 бит без знака) и int (16 бит со знаком).
Нужно проанализировать байт-код на минимальные/максимальные значения переменных. Как минимум, переменные цикла обычно ограничиваются условием i<константа. Если вместо константы переменная, то использовать её минимум/максимум, если выражение, то тоже можно, наверное, оценить его минимум/максимум. Если в программе нет рекрусивных вызовов, то достаточно будет обойти дерево вызова процедур (с уже известными минимумами/максимумами аргументов), иначе придётся делать несколько проходов. Ну и про статические переменные не забыть. Но в целом, эта задача стоит диссертации.