Переписать компайлер CP/Oberon под x86-64

[DIzer]

Под JVM Оберону будет довольно не уютно с тамошними либами - оттуда же как минимум исключения торчат. Под MSIL, подозреваю, будет то же самое. Алсо у Оберона нет интерфейсов вменяемых (и множественного наследования интерфейсов, даже у КП). То есть написание биндинга к очередной жабной либе будет сопровождаться болью

фиг бы сним, один черт проще чем писать сами либы...

а последующее использование этого биндинга - кровью из глаз.

А вот это самое страшное....

[DIzer]

Стоп а если я не ошибаюсь то вроде Влад собирался скрестить Оберон с ужо.. сорри жабоскриптом... интересно... каковы результаты?

[valexey_u]

Стоп а если я не ошибаюсь то вроде Влад собирался скрестить Оберон с ужо.. сорри жабоскриптом... интересно... каковы результаты?

Процесс идет :-)

[ilovb]

valexey_u, можно ссылку если знаешь где обсуждалось?

http://forum.oberoncore.ru/viewtopic.php?f=2&t=2439

Улыбнуло. 
Особенно речи о том, что нельзя трогать INTEGER ибо обратную совместимость нужно сохранить.
Ну цирк ей богу 
С чем обратная совместимость то? С коллекцией Хельмута Цинна?
Большая часть той коллекции нахер никому не впилась если уж совсем по чесноку. Помню курил код бьютифера тамошнего... это тихий ужас... чувак будто первый раз кодил. Уффф.
Вот без всякого зазрения совести это говорю, ибо это очевидно любому кто не мастурбирует на Оберон.

Ну, у народе же есть какие-то наработки. Та же учебная сборка. У Ильи вон тоже что-то рабочее есть. Если INTEGER менять, то получится самое плохое из того что может быть - врде бы все также, и даже что-то работает, но прри этом будет просто куча багов. Причем плохо вылавливаемых и в самых неожиданных местах.

Там же не только бинари придется выкинуть, но и прочесать ВСЕ исходники ББ на предмет завязки на 32битность. Без этого - будет постоянно что-то где-то глючить и отваливаться.

valexey, да какие нафик наработки? Если Илья устроил себе зависимость от текущей реализации BB, то это только его проблема. ЧЯ не развивается уже несколько лет и последняя версия не стабл нифига, а скорее ночная сборка под пивко 
Вот чем нужно руководствоваться чтобы полагаться на заброшенное ПО? Для меня загадка.
Все тру оберонщеги за бугром уже давно на ББ болт положили. И никто меня в обратном не переубедит, ибо у меня есть глаза, мозг и гугол.

Обратную совместимость делают не ради обратной совместимости. А токмо лишь потому, что объем уже-написанного-массово-пользуемого-прибыльного ПО превышает сотни человеко-лет труда. Т.е. это актуально для процов х86 и для венды и для линуха например, но для BB... не смешите меня ради всего святого 

Если уж действительно архитрудоемкая и полезная весчь сооружена в BB 1.6, ну и пусть сидит себе дальше на нем. Какая проблема? 

То есть по трудоемкости это сопоставимо с переписыванием ББ с нуля.

Ну тык от переписывания ББ профита больше имхо 

[vlad]

Стоп а если я не ошибаюсь то вроде Влад собирался скрестить Оберон с ужо.. сорри жабоскриптом... интересно... каковы результаты?

Ну я бы оценил, что оно на ~60% от момента, когда можно хоть в каком-то виде показать. Т.е. самое интересное (для меня) я уже реализовал, в том числе получен proof of concept - да, такой компилятор можно сделать и на жабаскрипте

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

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

[DIzer]

Стоп а если я не ошибаюсь то вроде Влад собирался скрестить Оберон с ужо.. сорри жабоскриптом... интересно... каковы результаты?

Ну я бы оценил, что оно на ~60% от момента, когда можно хоть в каком-то виде показать. Т.е. самое интересное (для меня) я уже реализовал, в том числе получен proof of concept - да, такой компилятор можно сделать и на жабаскрипте

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

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

спасибо, но меня больше интересует оценка удобства работы .. назовем его так - из оберон скрипта с  стандартными js либами (интерфейсами)  - дело в том, что я пробовал пользоваться адаптивными ИНЕТ технологиями от Борланда... и кроме самых простейших случаев оказывалось  что проще было перейти на наитивные.

[vlad]

спасибо, но меня больше интересует оценка удобства работы .. назовем его так - из оберон скрипта с  стандартными js либами (интерфейсами)  - дело в том, что я пробовал пользоваться адаптивными ИНЕТ технологиями от Борланда... и кроме самых простейших случаев оказывалось  что проще было перейти на наитивные.

Какой-то супер гладкой интеграции тоже не планируется Рабочая идея такая:

Код: [Выделить]

IMPORT js;
...
js.alert("Hello World!");

js - псевдомодуль типа SYSTEM. Все, что идет после "js." попадает непосредственно на исполнение жабоскрипту (с поправкой на обероновский синтаксис). Все, что возвращается из js - кастается к обероновским типам (не знаю еще как именно).

[qp]

По сабжу поддержу DIzer'а - забейте на натив. Пилите лучше GPCP. JVM/.NET на Ваш выбор.

Отстаем от жизни однако:

RE: [GPCP] Source files encoding in GPCP   
Posted By:      
john@...
Fri Nov 9, 2012 1:45 am  |
[...]
I am currently exploring the possibility of a major revision that includes
an LLVM-based native-code backend as well as the current .NET and JVM
backends. If this goes ahead then I will definitely do full Unicode as part
of the revision.

John [Gough]

[DIzer]

По сабжу поддержу DIzer'а - забейте на натив. Пилите лучше GPCP. JVM/.NET на Ваш выбор.

Отстаем от жизни однако:

RE: [GPCP] Source files encoding in GPCP   
Posted By:      
john@...
Fri Nov 9, 2012 1:45 am  |
[...]
I am currently exploring the possibility of a major revision that includes
an LLVM-based native-code backend as well as the current .NET and JVM
backends. If this goes ahead then I will definitely do full Unicode as part
of the revision.

John [Gough]

В каком это месте? отстаем.. We are  currently exploring too  Я бы сказал  - опережаем, ибо по причине отсутствия наш обьект не страдает падучей на каждый чих...

[Geniepro]

Большая часть той коллекции нахер никому не впилась если уж совсем по чесноку.

Какая жирная клевета.

Ага, а ведь полнолуние ещё не наступило...

[ilovb]

У меня свои фазы 
Ну а чо там ценного то? Кошерные вещи там по пальцам можно пересчитать

[Geniepro]

У меня свои фазы 
Ну а чо там ценного то? Кошерные вещи там по пальцам можно пересчитать

У Вас так мало пальцев? ))

[ilovb]

21 как у всех 
Ну ладно по пальцам одной руки тогда 

[qp]

В каком это месте? отстаем.. We are  currently exploring too  Я бы сказал  - опережаем, ибо по причине отсутствия наш обьект не страдает падучей на каждый чих...

Хе-хе,  имелось ввиду смелое пожелание 

забейте на натив

А в остальном - успехов в опережении