not a short message
Вид для печати
not a short message
Виталик, ты чего как отрезал?
raydac> А для чего вам ява-машина нужна?
Если есть желание что-то такое делать, ИМХО лучше смотреть в сторону LLVM (см. http://llvm.org/ ).
Там одно время был бэкэнд для PIC16, но автор перестал его поддерживать и в новых версиях его нет (из git-репозитария, естественно, все равно можно вытащить и посмотреть на него, см. бренч pic16 там).
Это интересно. Т.е. фактически компилятор?
Raydac, а транслирует в текстовый исходник или в готовый машинный код?
jerri, Вроде как было сказано, что
Цитата:
тренслирует в командны z80 найденные инструкции, никакой jvm там нету
Raydac, а отдельно текст можно посмотреть из того верхнего примера
---------- Post added at 12:48 ---------- Previous post was at 12:37 ----------
я имею ввиду полученный исходник
ужос
все через жо.. стек
это вот так работает джава? неудивительно что она везде тормозит
а та которая на портативных устройствах?
телефоны и тп?
Еще раз хочу указать на существование 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)
Друзья мои! Напоминаю что название топика "на Java для ZX"! Будьте бдительны! не дайте себе завлечь в обсуждение не по теме! :)
---------- Post added at 21:01 ---------- Previous post was at 20:52 ----------
У нас была система Lotus Domino, она зижделась на Java, ну очень уж тугая была система. Для сотиков Java прижилась потому что позволяла создать аппаратно независимое ПО (хотя есть и обратное мнение, опять же что с чем сравнивать). А касательно С++ - дотнет компилирует на старте приложения, и скорость говорят приличная и якобы аппаратная независимость и адаптивность.
JVM давно является JIT-системой.
А с Lotus Domino, как исконно IBM'овский продукт не может не тормозить. По долгу службы приходится очень много возиться с IBM/WebSphere и IBM-овскими j2ee-продуктами. Пишется все это дело индусами без каких либо оптимизаций.
Сорри за оффтоп.
---------- Post added at 20:31 ---------- Previous post was at 20:30 ----------
А вообще не плохо было бы для Спектрума иметь нативный транслятор и текстовый редактор с подсветкой синтаксиса :)
Тут надо реальнее смотреть на ситуацию. Eclipse на Спектруме никогда не запустится. А какое-то приложеньице для TR-DOS было бы приятно иметь даже с эстетической точки зрения: разрабатывать на Java на реале - такого еще не было :)
Я вот тут подумал, для вашей JVM можно использовать страничную память на машинах с >128 Кб ОЗУ. Скомпилированные классы можно располагать по страницам памяти. Правда для этого потребуется какой-то постоянный диспетчер, хранящий информацию о классах - номере страницы, стартовом адресе, и осуществляющем переключение страниц и условный переход в тело класса.
А еще интересно, как будет реализована многопоточность :)
---------- Post added at 21:52 ---------- Previous post was at 21:39 ----------
А еще я подумал. Java - это чистейший ООП. ООП идеология "правильной" программы - это сплошные абстракции, корректное проектирование "по Макконнеллу", шаблоны проектирования и проч. Любой Спектрум-кодер увидев код типичного j2ee-проекта впал бы в депрессию за нецелевое использование процессорных тактов :)
Но это так, размышления в воздух...
bigral, Ещё и ARM к тому же.
чего хоть делает то?
1753 байта же :(
он в таком объеме еще чегонибудь делать должен
у меня закрасил только 2/3 экрана
потом завис на зависалке.
полиморфизмы заценил да :)
J2ME это тоже 32-битная платформа. И там тоже нету беззнаковых числовых типов. И есть сборка мусора. К тому же другие разрешения экрана, чем у Спека. Не, ну наверно можно с потугами сделать хелловорлд, но портировать игры... Всё же лучше через Java Decompiler + ручной перевод на Оберон c последующей трансляцией через Ofront в Си и компиляцию SDCC. Предложите небольшую, но интересную игру, чтобы опробовать такую технологию. Кстати да, будет ещё запар с графикой, музыкой, звуком, а может и ещё с кое-чем.
Oleg N. Cher, есть еще j2ce
Да, но есть в этом практический смысл – эмулировать 32-битную архитектуру на 8-битной? Я думал, Вы предложите прямо с Java на C лучше писать, без Оберона как лишнего звена. :wink: Другое дело, что если там реально размер некоторых переменных можно ограничить 8 битами (со знаком или без), 16 битами (со знаком или без). Но выявить такие переменные можно только ручками.
Посмотрю.
Она всё равно основана на 8-битных байтах. И ничего там страшного нет: http://en.wikipedia.org/wiki/Java_by...ction_listings
Вы как-то не так трактуете мои высказывания, 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 хватило бы байта, со знаком или нет.
Нужно проанализировать байт-код на минимальные/максимальные значения переменных. Как минимум, переменные цикла обычно ограничиваются условием i<константа. Если вместо константы переменная, то использовать её минимум/максимум, если выражение, то тоже можно, наверное, оценить его минимум/максимум. Если в программе нет рекрусивных вызовов, то достаточно будет обойти дерево вызова процедур (с уже известными минимумами/максимумами аргументов), иначе придётся делать несколько проходов. Ну и про статические переменные не забыть. Но в целом, эта задача стоит диссертации.