Оберон-клуб «ВЄДАsoft»

Твердыня модульных языков
Текущее время: 15 дек 2019, 10:19

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




Начать новую тему Ответить на тему  [ Сообщений: 7 ] 
Автор Сообщение
 Заголовок сообщения: Обероны и кроссплатформенность
СообщениеДобавлено: 17 фев 2013, 15:23 
Не в сети
Аватара пользователя

Сообщения: 987
Откуда: Днепропетровская обл.
Продолжение темы разговора о достоинствах и недостатках Оберон-языков (ответ г-ну Веселовскому, отцу-основателю форума Oberspace).
Oleg N. Cher писал(а):
2. Базовые принципы, заложенные в него, позволяют надеяться, что какие бы процессоры и архитектуры не подсовывала нам промышленность, он туда ляжет. И наши алгоритмы и наработки не пропадут зря. Пример — мои попытки кодить мидлеты на GPCP. Там вроде всё настолько явошное, что фиг протолпишься. Ан нет. Можно ставить во главу угла сами алгоритмы, а не местное апи, главное сделать правильные привязки.
valexey писал(а):
Нет. В том смысле, что с портабельностью у Оберонов плохо. А на яву КП отлично ложится ровно потому, что КП изначально так и задумывался (все типы данных изначально под явовские подстроены). Попробуйте ка какой-нибудь алгоритм (например вычислительный) писаный для ББ на КП, перенести на 16ти битную платформу где целое число это 16ть бит и не больше. Радости будет МНОГО.

А вот не надо общие проблемы переноса кода большей разрядности на платформы меньшей разрядности полагать на язык Оберон. Моё мнение таково, что эта задача удовлетворительно не решена ни на одном языке программирования, тем более, уже не упоминая языки, которые могут транслироваться в 16- и 8-битные таргеты. В этом смысле немного идеальнее Модула-2 (за счёт беззнаковых типов и типов-диапазонов), но она из той же виртовской линейки. Но и она не решает эту проблему удовлетворительно.

А как можно решить эту задачу в ваших любимых языках, которые Вы намедни перечислили? C++, Ada, Haskell, Erlang. А никак. А как она решена в C#/Java? Фиксацией разрядности платформы? Поговорим о трансляции с этих языков в 16-битные таргеты? :) Самому не смешно? :) Для Оберона это хотя бы возможно на практике.

Как я на практике решаю на Обероне трудности разработки для платформ различной разрядности. Ну, лучше всего конечно же с самого начала вложить в алгоритмы возможность работать на типах, которые могут быть разной разрядности. Для этой цели я обычно завожу обёртки в модуле Platform:
Код: "OBERON"
  1. MODULE Platform; (* Модуль для обёрток типов.
  2.   Должен быть подогнан под реализацию транслятора Оберона. *)
  3.  
  4. IMPORT SYSTEM;
  5.  
  6. TYPE
  7. Octet* = SYSTEM.BYTE;
  8. Int8* = SHORTINT;
  9. Int16* = INTEGER;
  10. Int32* = LONGINT;
  11. Natint* = Int32; (* Родной (native) целый тип для платформы. *)
  12. Integer* = Natint;
  13. END Platform.

Ну и т.п. Основная идея, думаю, понятна. Так мы получаем типы с фиксированной разрядностью, которые в стандарте языка не предусмотрены, но благодаря такому модулю-конфигуратору ими можно успешно пользоваться. Если подумать о беззнаковых типах, то мы можем прийти к выводу, что они такой же разрядности, а к беззнаковым можно отнести только ряд операций (умножение, деление, сравнение и т.д.). Эти операции можно реализовать внешним модулем (для эффективности работы кода на 8- и 16-битных процессорах). В Ofront есть возможность описать их на уровне Оберона процедурно, а на уровне Си в виде макросов приведения типа и операций, что уберёт оверхед. Таким образом, благодаря такой двухуровневой схеме появляются возможности, которые трудно было подозревать в Оберон-технологиях с самого начала, ведь первым делом в глаза бросается скромность средств, а вовсе не их чрезмерность и избыточность.

Вобщем, я крайне не согласен с высказыванием, что с портабельностью у Оберонов плохо. У них с портабельностью всё крайне хорошо. Самое узкое место портабельности Оберонов — разрядность типов. И эта же проблема есть у любого другого средства, на котором можно разрабатывать портабельные решения. Только кое-где проблема замылена приведением разрядности к 32 битам, что не решает вообще никак проблему переноса на меньшую разрядность. А в ряде средств разработки (скриптовых языках) данная проблема вообще никак не решается в принципе, ибо разработанные на них программы не могут работать на процессорах с разрядностью ниже 32 бит.

Вам кажется странным, что что типы КП чем-то принципиально связаны с типами в Java? Батенька, это не Java. Это здравый смысл. Раньше, когда платформы были 16-битные, разумно было иметь 8, 16 и 32 бита. Сейчас доминируют 32-битные (и больше) платформы. И разумно иметь типы размером 8, 16, 32 и 64 бита. Разумно иметь 2-байтовый CHAR. Кстати, в Обероне-07 Вирт тоже избавился от 8- и 16-битного балласта, обеспечив языку портабельность в рамках >= 32 бит, фактически явовского и дотнетного типа.

Чтобы проиллюстрировать портабельность Оберонов на практике вот порт игры Dash для 8-, 16- и 32-битных платформ. В чём-то этот проект уникален, хоть и не закончен, и уж точно нечто подобное невозможно на многих современных средствах разработки. Поспорить с Обероном тут могут Модула-2 и Си, но Оберон — развитие Модулы-2. И, раз мы на этом форуме, значит понимаем преимущества Оберона перед Си, не так ли?


Вернуться к началу
 Профиль  
Ответить с цитатой  
СообщениеДобавлено: 18 фев 2013, 18:15 
Не в сети

Сообщения: 13
Zorko писал(а):
Поговорим о трансляции с этих языков в 16-битные таргеты? :)

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

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

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


Вернуться к началу
 Профиль  
Ответить с цитатой  
СообщениеДобавлено: 18 фев 2013, 20:43 
Не в сети
Аватара пользователя

Сообщения: 987
Откуда: Днепропетровская обл.
Да, это проблема компилятора. И даже для LLVM можно создать 16- и 8-битный таргет. Но это только теоретически звучит хорошо. На практике языки, у которых в стандарте основная разрядность целых 32/64 бита (или вообще не оговорена, а значит считается максимально возможной, как в PHP) будут генерировать чудовищно неэффективный код для 8- и 16-битных процессоров.

В идеале язык должен иметь один числовой (или вариативный) тип данных, а разрядность вычислений не должна волновать программиста и определяться автоматически компилятором, что и по сей день непростая задача. Вы же видите как на практике решается определение разрядности вычислений. Приведением к большой разрядности. С появлением дешёвых мобильных устройств с 64-битными процессорами ситуация с автоматическим определением поддиапазонов вычислений компилятором вряд ли будет вообще как-то решаться.

Идеальное абстрагирование от числовых компьютерных вычислений всё равно недостижимо. Мы по-прежнему пользуемся подмножеством целых, хоть и возросшим до почти удовлетворительного. По-прежнему есть потребность в плавающих вычислениях с различной точностью (скоростью). Да, согласимся, что появление 32/64-битных процессоров дало нам в руки хорошее приближение вычислений к идеальному варианту. Старые архитектуры остались за бортом, и это мало кого волнует уже. У них к тому же проблемы с адресацией больших объёмов памяти и т.п.

Мне всё же нравится система типов Оберона-1 и 2. Три базовых числовых типа, без которых на практике всё равно очень сложно обойтись (в системных задачах — вообще не обойтись): SHORTINT, INTEGER и LONGINT (в ETH Oberon есть тип HUGEINT). В ряде случаев полезен SYSTEM.BYTE, хотя он и не для вычислений. Беззнаковые типы отсутствуют, что убирает множество проблем совместного использования знаковых и беззнаковых типов (Кстати с вырастанием разрядности и появлением новых эффективных команд в процессорах беззнаковые типы вообще становятся всё менее и менее актуальными). То, что базовые типы Оберона не привязаны к разрядности, явовец может быть назовёт недостатком. Как это преодолеть — я написал постом выше (модулем-обёрткой для типов). То, что на Обероне можно успешно разрабатывать для 8- и 16-битных платформ, извините, недостатком языка не считаю. Напротив.

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

    1. Один абстрактный числовой тип, включающий максимально возможный (для конкретной платформы) диапазон значений. Можно иметь один числовой тип для целых и вещественных. Или универсальный вариантный тип (как в PHP). Плюс: меньше заморочек с поддиапазонами, нет ручных преобразований длинных чисел в короткие, знаковых в беззнаковые и т.п. Минус: на 8- и 16-битных процессорах этот тип может иметь недостаточную для задачи разрядность или же неэффективную реализацию. На платформах с различными числовыми возможностями будет меняться мощность числового типа, что несомненно приведёт к программной несовместимости.

    2. Один числовой целый тип, привязанный к базовой разрядности платформы (например, 32 бит. Или “не меньше чем 32 бит”). В ряде случаев может быть дополнен типом для вычислений повышенной точности. Тут уже с совместимостью повеселее, но 8- и 16-битные архитектуры за бортом.

    3. Зоопарк типов, как с явно указанной разрядностью, так и с неявно. Или и то, и другое. В этом случае проецирование числовых вычислений на размер типов ложится на и без того бедные плечи программиста. Бывают ситуации, когда на одной платформе эффективнее пользоваться 32-битным типом данных, на другой 8-битным, а для решаемой задачи достаточно восьми бит. Тогда приемлемо использовать базовый числовой тип без явного указания разрядности. Хотя и необходимо иметь ввиду минимально достаточный диапазон значений для вычислений.

Потенциально самым привлекательным кажется первый вариант, но если компилятор будет автоматически подстраиваться под архитектуру и балансировать между точностью и эффективностью реализации. В Оберонах вовсю используется третий. В Java большей частью второй, хотя и с некоторой добавкой третьего (есть байт (8 бит) и короткое целое (16 бит)). Впрочем, заметьте, никто не мешает нам при программировании на Обероне-2/КП использовать первый вариант (взяв за основу целого адресацию платформы в 32 бита на 32-битных платформах и 64 бита на 64-битных), второй вариант (как в Обероне-07. Ну просто не пользоваться длинными и короткими целыми, для всего используя один основной числовой тип (прямо или через модуль-обёртку) и, разумеется, третий, т.к. он для Оберонов (кроме 07) естествен. Привязку к явно указанной разрядности в этом случае, опять же, делаем через модуль-обёртку для типов.

Так что я не понимаю почему г-н Веселовский придирается к портабельности Оберонов. Тот же ETH Oberon крутится гостевой системой почти на любой платформе от Амиги до 16-битного MS DOS'а. Более под критику подпадает Оберон-07 (чистый вариант 2) или Си (в котором тоже не закреплена привязка типов к разрядности (а решено это в более поздних стандартах примерно тем же способом, что я предложил выше для Оберонов)). А может он как почитатель Оберона-07 просто не умеет готовить остальные Обероны? :o Позволяющие использовать любой из трёх приведённых выше вариантов решения проблем портабельности, и их вариации. :) А ведь языки, которые хвалит г-н Веселовский, не предлагают ничего нового на пути решения переноса программ на платформы с меньшей разрядностью. Ну что ж, тогда пусть он расскажет нам о прекрасных портабельных средствах разработки, подходящих для переноса программ с бОльшей разрядности на меньшую. И каким образом это реализовано. Или препредложит ещё вариантов, — как по его мнению должна решаться эта проблема раз и навсегда. ;)


Вернуться к началу
 Профиль  
Ответить с цитатой  
СообщениеДобавлено: 20 фев 2013, 18:29 
Не в сети

Сообщения: 13
Zorko писал(а):
На практике языки, у которых в стандарте основная разрядность целых 32/64 бита (или вообще не оговорена, а значит считается максимально возможной, как в PHP) будут генерировать чудовищно неэффективный код для 8- и 16-битных процессоров.

Zorko писал(а):
Да, согласимся, что появление 32/64-битных процессоров дало нам в руки хорошее приближение вычислений к идеальному варианту. Старые архитектуры остались за бортом, и это мало кого волнует уже. У них к тому же проблемы с адресацией больших объёмов памяти и т.п.

Сопоставляя эти два высказывания, я прихожу к выводу, что проблемы нет.


Вернуться к началу
 Профиль  
Ответить с цитатой  
СообщениеДобавлено: 09 мар 2013, 15:41 
Не в сети

Сообщения: 53
Откуда: Россия, Самара
Очень интересная тема. Хотел бы уточнить.

Не могли бы вы написать недостатки разных типов абстрагирования. К примеру есть ли недостатки у первого типа абстрагирования, на 32 и 64 битном процессоре.

Если использовать один тип для всего, увеличивается использование озу(что не критично). Есть ли ещё проблемы?

Не будет ли отсутствие беззнаковых типов усложнять программирование?

Пример.

Допустим у нас есть функция создания кнопки. Button.Create(PosX, PosY, SizeX, SizeY: integer);
integer 4 байта со знаком.
Если передать к примеру <0 ничего не будет отрисовано, как выявить ошибку без использования исключений? Но если использовать integer без знака компилятор сам сможет проверить типы и в данном случае ручная проверка не нужна.


Вернуться к началу
 Профиль  
Ответить с цитатой  
СообщениеДобавлено: 09 мар 2013, 18:20 
Не в сети
Аватара пользователя

Сообщения: 987
Откуда: Днепропетровская обл.
Jordan писал(а):
Не могли бы вы написать недостатки разных типов абстрагирования.
Ну вкратце я и так написал их.

Вольность использования зоопарка типов должна диктоваться задачами. Системным задачам нужны различные типы, и беззнаковые тоже (или их эмуляция — в Обероне средствами MOD). Если задачи достаточно далеки от точной привязки к разрядности, то, в принципе, можно делать программу на 32-битных типах, смело ожидая её нормальной работы на 64 битах.

Jordan писал(а):
К примеру есть ли недостатки у первого типа абстрагирования, на 32 и 64 битном процессоре. Если использовать один тип для всего, увеличивается использование озу(что не критично). Есть ли ещё проблемы?
Проблемы в этом случае могут возникнуть если программист посчитает этот неявный тип как минимум 64-битным, а потом захочет (он сам или кто-то другой) собрать программу транслятором, в котором данный тип будет трактоваться как 32-битный. Больше вроде проблем действительно нет.

Вопрос “привязывать ли типы языка к определённой разрядности стандартом?”, скорее, философский. На практике можно успешно программировать на языках с такой привязкой, или без неё.

Jordan писал(а):
Не будет ли отсутствие беззнаковых типов усложнять программирование?
В начале освоения Оберон-технологий мне казалось, что будет, и что это большая проблема. На самом деле без них даже проще. Чистый беззнаковый тип нужен мало и редко где. В несистемных задачах, где вам просто нужно неотрицательное значение, вполне неплохо подходит тип со знаком. Ведь если нам нужно число-аргумент в процедуру от 0 до 255 — мы же не стараемся запихнуть его именно в байт. Достаточно просто иметь ввиду, что:
Код: "OBERON"
  1. ASSERT((arg >= 0) & (arg <= 255));

Я попытался на практике выяснить, что же будет из себя представлять на вкус Оберон с беззнаковыми типами. Добавив всего пару сущностей в язык получилось много привнесённых тонкостей и проблем. (Но это делается для разработки на Обероне для 8-битной платформы). Вот, например, сегодня обнаружил, что при работе с беззнаковыми типами цикл:
Код: "OBERON"
  1. VAR i: CARDINAL;
  2. BEGIN
  3. FOR i := 4 TO 0 BY -1 DO ... END
согласно стандарту языков Оберон/КП никогда не закончится. Как вам такой сюрпризец? Нет, ну вот кто бы подумал, а всё честно исходит из соглашения о языке. Подробнее здесь.

Так что привычка иметь под рукой беззнаковые типы рудиментом проистекает из старых процессоров и поддерживающих эффективную кодогенерацию для них языков программирования. Просто привычка. От которой, отвыкнув, становишься свободнее от груза давящих преобразований между знаковыми и беззнаковыми и общей концептуальной перегруженности количеством типов и их поддиапазонов. Подробнее об этом я слегка не в тему писал на Oberspace. Определённо, решение проф. Вирта оставить в Обероне-07 всего один целочисленный тип — здравый шаг. Непривычный, но дающий свои преимущества, которые нужно изучать.

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

Jordan писал(а):
Допустим у нас есть функция создания кнопки. Button.Create(PosX, PosY, SizeX, SizeY: integer);
integer 4 байта со знаком.
Если передать к примеру <0 ничего не будет отрисовано, как выявить ошибку без использования исключений? Но если использовать integer без знака компилятор сам сможет проверить типы и в данном случае ручная проверка не нужна.
А если передать в эту процедуру заведомо неверное значение, например, MAX(INTEGER)? :) Хорошо, в данном случае проверку на неотрицательность можно поручить компилятору, но можно найти сто случаев, где неверное значение не будет определяться так просто.

Предлагаю не отказываться от исключений и внутри этой процедуры ловить отрицательные числа ASSERT'ом. Также как и выход за пределы возможных значений, если это требуется. Тогда в рантайме мы получим очень внятное сообщение, где именно произошла передача неверного значения аргумента. Ценная практика, позволяющая выявлять ошибки на ранних стадиях работы.

Интересное наблюдение: у начинающих программистов никогда не возникает потребность в беззнаковых типах. Наоборот, их может слегка удивить почему числа делятся на целые и вещественные. И разный размер точности целых тоже требует дополнительных пояснений. Это матёрые возросшие на TurboPascal/TurboC программисты обожают эти типы. Оберон же нас подводит к тому верному мнению, что чисто беззнаковая арифметика — частный случай целочисленной арифметики, и предназначена больше всё-таки для системных низкоуровневых нужд (или для повышения эффективности вычислений на старых 8- и 16-битных процессорах).

Вот в BlackBox все беззнаковые аргументы процедур WinApi спокойненько сделаны знаковыми, и это мало кого смущает. Хотя не будем кривляться, в ряде случаев они нужны таки беззнаковые. Но и это мало кого смущает. Нормальная практика при работе в Оберон-парадигме.

Если уж нам точно припекло работать с беззнаковыми данными — берём (в BlackBox)

    для байта: b MOD 100H
    для 16-битного SHORTINT: s MOD 10000H
    для 32-битного INTEGER: LONG(i) MOD 100000000HL

Как достичь беззнакового LONGINT? Ну, например, использовать модуль, который реализует операции для беззнаковых вычислений (автор: Robert D Campbell), как-то проскакивал по рассылке ББ (я включил его в XDev).

А чтобы повысить наглядность описания вашей процедуры можно воспользоваться алиасом для типа INTEGER, я так делал когда работал над биндингом SDL:
Код: "OBERON"
  1. TYPE
  2. Integer = Platform.Integer; (* Это чтобы вынести точное указание разрядности в обёртку. *)
  3. Cardinal = Integer; (* Указываем, что в эти переменные надо передавать значения >= 0. *)
  4.  
  5. PROCEDURE (VAR button: Button) Create (PosX, PosY, SizeX, SizeY: Cardinal); (* Также будет и в интерфейсе. *)
Ещё один философский вопрос: включить в язык всевозможные (в частности, беззнаковые) типы данных на все случаи жизни, что всё равно почти невозможно, и это прямой путь превратить язык в сверхбольшого монстра, к которому всё равно рано или поздно возникнут претензии: почему нету комплексного типа и проч. Или же внедрить в язык компактный механизм создания новых типов, как это сделано в OPCL, ETH Oberon и Active Oberon средствами расширения OberonX.

Так что можно попробовать сконструировать беззнаковые типы дополнительным модулем, реализующим беззнаковую арифметику (как модуль Cardinals подсистемы Multi) или средствами OberonX, а в XDev беззнаковые типы уже реализованы, но требуют обкатки, как и сама XDev.

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


Вернуться к началу
 Профиль  
Ответить с цитатой  
СообщениеДобавлено: 12 мар 2013, 10:47 
Не в сети
Администратор
Аватара пользователя

Сообщения: 269
Откуда: Россия
Цитата:
Я попытался на практике выяснить, что же будет из себя представлять на вкус Оберон с беззнаковыми типами. Добавив всего пару сущностей в язык получилось много привнесённых тонкостей и проблем. (Но это делается для разработки на Обероне для 8-битной платформы). Вот, например, сегодня обнаружил, что при работе с беззнаковыми типами цикл...согласно стандарту языков Оберон/КП никогда не закончится. Как вам такой сюрпризец? Нет, ну вот кто бы подумал, а всё честно исходит из соглашения о языке.
Ну конечно же, это та же самая проблема, что я разбираю в теме http://zx.oberon2.ru/forum/viewtopic.php?f=46&t=83 (и даже отразил в подписи :) ). Нет принципиальной разницы, в возрастающим или убывающем порядке идет цикл, используется ли лишний инкремент или декремент, в результате чего возникает (анти)переполнение. Выход за нижнюю границу ведет к таким же неприятностям, как и превышение верхней. И это проблема не беззнаковых типов, на границе типов LONGINT, INTEGER, SHORTINT происходит то же самое.
У безнаковых типов эта проблема острее, потому что вблизи ноля (нижняя граница беззнаковых) приходится работать чаще, чем около больших по абсолютной величине границах INTEGER. А у 8\16-разрядных типов маленький диапазон, который в системных целях чаще всего надо перебрать весь.
Однако любой целочисленный тип ограничен и проблема не в наличии границ, а в бесконтрольном выходе за них.

_________________
А кроме того, я думаю, что корFORген должен быть разрушен!


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

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


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

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


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

Найти:
Перейти:  
cron
Создано на основе phpBB® Forum Software © phpBB Group
© VEDAsoft Oberon Club