Oberon space
General Category => Общий раздел => Тема начата: valexey_u от Декабрь 13, 2012, 02:05:15 pm
-
Что делать если мне нужно обрабатывать 32 bit unsigned int (к рассчетам это отношения не имеет, чисто програмистская задачка, грубо говоря, это индексы)? Оно же в INTEGER не влезет никак, при условии что INTEGER в нашей реализации таки 32битный (вроде бы в этом Обероне нигде битность INTEGER'a гвоздями не прибита).
Единственный выход который я вижу, использовать LONGREAL (и надяеться что во всех реализациях этого Оберона LONGREAL будет хотя бы 64битным).
-
на оберонкоре это решают просто ))
Заголовок: Получить беззнаковое значение BYTE (http://forum.oberoncore.ru/viewtopic.php?p=76448#p76448)
Да, с беззнаковыми целыми в Оберонах проблемы ))
К счастью разработчики А2 решили от этой злостной проблемы избавиться.
Проблемы в головах.
Удалено, согласно пп. 1.3, 1.19, 1.9 правил.
-
на оберонкоре это решают просто ))
С BYTE в Блэкбоксе можно сделать так:
PROCEDURE SignedToUnsigned (x: BYTE): INTEGER;
VAR ch: CHAR;
BEGIN
ch := CHR(x);
RETURN ORD(ch);
END SignedToUnsigned;Временная переменная ch: CHAR; обязательна. Если подставить напрямую ORD(CHR(x)), то компилятор соптимизирует и возвратит отрицательное число при отрицательном x.
-
на оберонкоре это решают просто ))
С BYTE в Блэкбоксе можно сделать так:
PROCEDURE SignedToUnsigned (x: BYTE): INTEGER;
VAR ch: CHAR;
BEGIN
ch := CHR(x);
RETURN ORD(ch);
END SignedToUnsigned;Временная переменная ch: CHAR; обязательна. Если подставить напрямую ORD(CHR(x)), то компилятор соптимизирует и возвратит отрицательное число при отрицательном x.
Какие хаки однако нужны в КП ;-) Да еще и компиляторозависимые.
-
Что делать если мне нужно обрабатывать 32 bit unsigned int
Пожалуй, лучшее, что можно сделать в этом случае, - это не использовать Оберон.
-
А как же SET, или он не 32 бита ?
-
Что делать если мне нужно обрабатывать 32 bit unsigned int
Пожалуй, лучшее, что можно сделать в этом случае, - это не использовать Оберон.
по этому хорошо бы знать когда использовать его , а когда нет - а еще лучше когда и где его использование оптимально ( я говорю про 07) - в исходном варианте я перспектив его использования.. не вижу.. даже на начальном этапе обучению алгоритмизации...
-
на оберонкоре это решают просто ))
Заголовок: Получить беззнаковое значение BYTE (http://forum.oberoncore.ru/viewtopic.php?p=76448#p76448)
Да, с беззнаковыми целыми в Оберонах проблемы ))
К счастью разработчики А2 решили от этой злостной проблемы избавиться.
Проблемы в головах.
Удалено, согласно пп. 1.3, 1.19, 1.9 правил.
кстати.. при переходе по ссылке выдает что такой темы не существует... Kemet - а не вводите ли вы нас в заблуждение :o
-
на оберонкоре это решают просто ))
Заголовок: Получить беззнаковое значение BYTE (http://forum.oberoncore.ru/viewtopic.php?p=76448#p76448)
Да, с беззнаковыми целыми в Оберонах проблемы ))
К счастью разработчики А2 решили от этой злостной проблемы избавиться.
Проблемы в головах.
Удалено, согласно пп. 1.3, 1.19, 1.9 правил.
кстати.. при переходе по ссылке выдает что такой темы не существует... Kemet - а не вводите ли вы нас в заблуждение :o
эта тема действительно была
-
всего за пару часов убрали... оперативно, однако.
-
на оберонкоре это решают просто ))
...
Удалено, согласно пп. 1.3, 1.19, 1.9 правил. (http://forum.oberoncore.ru/viewtopic.php?p=76448#p76448)
Я уже писал где-то на оберонкоре, что они сильно вредят своему сайту, Оберону и всему сообществу тем, что не приемлют никакой критики Оберона. Вот такой парадокс, в чём-то не плохо продвигают, а в чём-то - вредят. Прав Евгений Темиргалеев, проблемы в головах. Весь вопрос в том, в чьих...
-
на оберонкоре это решают просто ))
...
Удалено, согласно пп. 1.3, 1.19, 1.9 правил. (http://forum.oberoncore.ru/viewtopic.php?p=76448#p76448)
Я уже писал где-то на оберонкоре, что они сильно вредят своему сайту, Оберону и всему сообществу тем, что не приемлют никакой критики Оберона. Вот такой парадокс, в чём-то не плохо продвигают, а в чём-то - вредят. Прав Евгений Темиргалеев, проблемы в головах. Весь вопрос в том, в чьих...
тык, ну ладно сообщение удалили... но зачем ВСЮ ТЕМУ удалять... уроды моральные.. еще и трусливые... другого эпитета не могу подобрать...
-
А как же SET, или он не 32 бита ?
Ну и что, что 32 бита? Внутренний формат хранения у SET полностью совпадает с integer unsigned, но снаружи-то он не integer.
-
Просто нужно тогда точнее выражаться, зачем нужно иметь именно 32 битное целое без знака. Если для индексации массива, то можно иметь 2 массива, а по старшему биту множества определять какой из этих массивов использовать...
-
тык, ну ладно сообщение удалили... но зачем ВСЮ ТЕМУ удалять... уроды моральные.. еще и трусливые... другого эпитета не могу подобрать...
Самое глупое, что можно придумать, - это пытаться утаить очевидные недостатки (темы вырезать, гнобить инакомыслящих и т.д.). На мой взгляд, Оберон - отличный язык, и я не вижу пока для себя замены ему. В то же время я признаю, что у него есть свои недостатки. Я стараюсь относиться к Оберону как к рабочему инстументу, без излишнего фанатизма.
-
Просто нужно тогда точнее выражаться, зачем нужно иметь именно 32 битное целое без знака.
Не понял, кому нужно точнее выражаться?
Если для индексации массива, то можно иметь 2 массива, а по старшему биту множества определять какой из этих массивов использовать...
То есть Вы предлагаете эмулировать недостающий бит?
-
на оберонкоре это решают просто ))
С BYTE в Блэкбоксе можно сделать так:
PROCEDURE SignedToUnsigned (x: BYTE): INTEGER;
VAR ch: CHAR;
BEGIN
ch := CHR(x);
RETURN ORD(ch);
END SignedToUnsigned;Временная переменная ch: CHAR; обязательна. Если подставить напрямую ORD(CHR(x)), то компилятор соптимизирует и возвратит отрицательное число при отрицательном x.
Какие хаки однако нужны в КП ;-) Да еще и компиляторозависимые.
ИМХО - ничего необычного.. такое встречается часто, когда ЯВУ - используется не по назначению.., я вот про что - говорить правильно это или нет можно только в некотором контексте...
-
Самое глупое, что можно придумать, - это пытаться утаить очевидные недостатки (темы вырезать, гнобить инакомыслящих и т.д.). На мой взгляд, Оберон - отличный язык, и я не вижу пока для себя замены ему. В то же время я признаю, что у него есть свои недостатки. Я стараюсь относиться к Оберону как к рабочему инстументу, без излишнего фанатизма.
1.Тут я могу сказать с вероятностью 90% - это есть следствие низкого интеллекта (позорно, конечно, диагностировать его у преподавателей .. но ..)
2. А вот насчет второго - пожалуйста, поделитесь - чего там уникального, чего нет в других в других языках.. можете просто назвать ОБЛАСТЬ ИСПОЛЬЗОВАНИЯ где, по вашему мнению, ему нет замены.
-
На мой взгляд, Оберон - отличный язык, и я не вижу пока для себя замены ему. В то же время я признаю, что у него есть свои недостатки. Я стараюсь относиться к Оберону как к рабочему инстументу, без излишнего фанатизма.
поделитесь - чего там уникального, чего нет в других в других языках.. можете просто назвать ОБЛАСТЬ ИСПОЛЬЗОВАНИЯ где, по вашему мнению, ему нет замены.
Сейчас развелось столько языков, что любому языку в любой области наверное можно найти замену. Я же написал, что не вижу ДЛЯ СЕБЯ замены. То есть другие языки субъективно мне кажутся хуже. Оберон я использую в основном для вычислительных задач в инженерной практике. Один раз по работе пришлось написать небольшую программку на Си, - изматерился весь! :)
-
Сейчас развелось столько языков, что любому языку в любой области наверное можно найти замену. Я же написал, что не вижу ДЛЯ СЕБЯ замены. То есть другие языки субъективно мне кажутся хуже. Оберон я использую в основном для вычислительных задач в инженерной практике. Один раз по работе пришлось написать небольшую программку на Си, - изматерился весь! :)
какой Оберон... я спрашиваю не просто так.. история имеет тенденцию повторяться - около года назад был Rifat, сейчас Akron... а воз и ныне там, так и непонятно (мне , по крайней мере) - нафига это нужно...- можно сделать портабельность, можно 64битность, можно хорошую IDE... - но ради чего?
-
На мой взгляд, Оберон - отличный язык, и я не вижу пока для себя замены ему. В то же время я признаю, что у него есть свои недостатки. Я стараюсь относиться к Оберону как к рабочему инстументу, без излишнего фанатизма.
поделитесь - чего там уникального, чего нет в других в других языках.. можете просто назвать ОБЛАСТЬ ИСПОЛЬЗОВАНИЯ где, по вашему мнению, ему нет замены.
Сейчас развелось столько языков, что любому языку в любой области наверное можно найти замену. Я же написал, что не вижу ДЛЯ СЕБЯ замены. То есть другие языки субъективно мне кажутся хуже. Оберон я использую в основном для вычислительных задач в инженерной практике. Один раз по работе пришлось написать небольшую программку на Си, - изматерился весь! :)
Вполне верю. Для чисто инженерных рассчетов, если сидеть на конкретной реализации Оберона, то это будет в среднем выгодней чем делать то же на Сях (если не требуется эти рассчеты перетаскивать с платформы на платформу). В общем то тут вполне и какого-нибудь PL/I хватит (см. соседнюю тему про Российский PL/I, там как раз оно. причем на весьма приличном уровне).
Это не относится к С++ конечно же - С++ лучше для инженерии (всякое там dsp и численные методы) чем Си и Оберон. (но с другой стороны, чтобы на С++ было удобно и просто писать всякую инженерию, нужно инвестировать в обучение вполне осмысленное время).
-
а воз и ныне там, ...
Какой воз? Не, мне портабельность по барабану. У нас на работе лицензионная Венда - это корпоративный стандарт, изменений не предвидится.
Да, если требуется GUI, то иногда на дельфях пишу. Но после Оберона испытываю при этом дискомфорт. Особенно раздражают регистронечувствительные идентификаторы.
(Блэкбокс, кстати, забросил. Использую консольный копилятор XDS)
-
на оберонкоре это решают просто ))
С BYTE в Блэкбоксе можно сделать так:
PROCEDURE SignedToUnsigned (x: BYTE): INTEGER;
VAR ch: CHAR;
BEGIN
ch := CHR(x);
RETURN ORD(ch);
END SignedToUnsigned;Временная переменная ch: CHAR; обязательна. Если подставить напрямую ORD(CHR(x)), то компилятор соптимизирует и возвратит отрицательное число при отрицательном x.
Какие хаки однако нужны в КП ;-) Да еще и компиляторозависимые.
ИМХО - ничего необычного.. такое встречается часто, когда ЯВУ - используется не по назначению.., я вот про что - говорить правильно это или нет можно только в некотором контексте...
Потому, что компилятор не имеет права оптимизировать таким образом, чтобы меналясь семантика действия. В нормальных высокоуровневых языков в описании учитывается тот факт, что в мире существует оптимизация, и поэтому там задется некий базис, набор инвариантов которые при оптимизации должны сохраняться.
Если у меня в зависимости от опций оптимизации функция:
int_least32_t s_to_us(int_least8_t a) { return (uint_least8_t)a;}
при одном и том же входном значении в диапазоне [-127;127] будет возвращать разные значения, то это будет форменным безобразием.
А в КП (точнее в случае ББ) это считается обычным делом.
В принципе теперь понятно почему там народ так боится оптимизирующих компиляторов :-)
-
а воз и ныне там, ...
Какой воз? Не, мне портабельность по барабану. У нас на работе лицензионная Венда - это корпоративный стандарт, изменений не предвидится.
Ну, платформа это еще и конкретный компилятор и конкретный процессор (например потребуется 64 бита да еще с векторизацией + какая-нибудь CUDA). Ну и сама винда широка и необъятна. Иногда и под .net неплохо бы иметь возможность собрать ровно ту же прогу. А теперь еще и ARM, и тоже винда ;-)
Да, если требуется GUI, то иногда на дельфях пишу. Но после Оберона испытываю при этом дискомфорт. Особенно раздражают регистронечувствительные идентификаторы.
Странно. Это то как раз скажем в Аде меня не раздражало.
(Блэкбокс, кстати, забросил. Использую консольный копилятор XDS)
А почему, если не секрет?
-
(Блэкбокс, кстати, забросил. Использую консольный копилятор XDS)
А почему, если не секрет?
Пиши что хочешь, ныкай сырцы, и совесть при этом спокойна :D
А вообще, о некоторых недостатках Блэкбокс я на оберонкоре писал, и дальше развивать эту тему не хочу. Напомню только некоторые: завязка на COM, хаки в компиляторе, небрежность в коде (какие-то "левые" ключевые слова, которые забыли закомментарить), неработающие опции компилятора и т.д.
-
на оберонкоре это решают просто ))
С BYTE в Блэкбоксе можно сделать так:
PROCEDURE SignedToUnsigned (x: BYTE): INTEGER;
VAR ch: CHAR;
BEGIN
ch := CHR(x);
RETURN ORD(ch);
END SignedToUnsigned;Временная переменная ch: CHAR; обязательна. Если подставить напрямую ORD(CHR(x)), то компилятор соптимизирует и возвратит отрицательное число при отрицательном x.
Я конечно зануда, но я не поленился, и проверил. Вначале я сходил в доку по КП (cюда: http://plas.fit.qut.edu.au/gpcp/LanguageReport.aspx#Type ), выяснил, что char он таки 16ти битный в КП (вне зависимости от реализации), а байт это натурально sint8. И тут то у меня и закрались подозрения.
Сходил и пощупал что у нас выйдет на плюсах:
#include <iostream>
#include <stdint.h>
using namespace std;
int main()
{
int_least8_t b = -15;
cout << (int_least32_t)(uint_least16_t)b;
return 0;
}
Получил естественны на выходе не 241 как ожидалось, а совсем даже 65521. Оке-ей. Скачал себе ББ. Проверил:
MODULE ObxHello0;
IMPORT StdLog;
PROCEDURE SignedToUnsigned (x: BYTE): INTEGER;
VAR ch: CHAR;
BEGIN
ch := CHR(x);
RETURN ORD(ch);
END SignedToUnsigned;
PROCEDURE Do*;
BEGIN
StdLog.Int(SignedToUnsigned(-15));
END Do;
END ObxHello0.
Получил в логе те же самые 65521. Так что этот метод не позволяет засунуть в integer тот самый uint8.
Чтобы работало как надо, в КП нужно немножко допилить:
PROCEDURE SignedToUnsigned (x: BYTE): INTEGER;
VAR ch: CHAR;
BEGIN
ch := CHR(x);
RETURN ORD(BITS(ORD(ch)) * {0,1,2,3,4,5,6,7});
END SignedToUnsigned;
И тогда все хорошо.
PS. Проверил на счет оптимизации - в ББ действительно компилятор кривой, оптимизацию он делает не верно. На выходе получается -15.
-
Ну, либо вместо CHAR использовать SHORTCHAR
-
Тема не удалялась, она на месте.
Вы пытаетесь пойти по ссылке на отдельное сообщение.
-
зачем нужно иметь именно 32 битное целое без знака
Как работать с памятью выше 2-х гигабайт, не имея беззнаковых целых? В А2 не смогли, поэтому решили таки эти беззнаковые там реализовать. Как обработать файл, размером больше 2-х гб, не вводя 64-х битное знаковое целое там, где оно совершенно не нужно?
-
Лично я использую в качестве аналога сишного size_t (для позиций, длин и проч.) уже пару лет как только LONGINT. Ибо придерживаюсь в своём коде "64-bit-ready".
-
in CP, for unsigned int(8,16), just use MOD operator:
uint8 := x MOD 256;
uint16 := x MOD 65536;
-
...
Я конечно зануда, но я не поленился, и проверил. Вначале я сходил в доку по КП (cюда: http://plas.fit.qut.edu.au/gpcp/LanguageReport.aspx#Type ), выяснил, что char он таки 16ти битный в КП (вне зависимости от реализации), а байт это натурально sint8. И тут то у меня и закрались подозрения.
....
Много слов - но суть сводится к тому, что КП - (точнее его ББ - реализация), плохо подходит для низкоуровневого программирования (точнее его задач), но тут вы вступаете в противоречие, с высказыванием Ильи - о том, что ИМЕННО для этой области ББ хорош... - тут либо кто-то из вас неправ, либо нужно уточнять эту возможную область использования КП. Пока, у меня не вызывает противоречивых ощущений только ниша , где сидит Инфо21 (научное самопальное прототипирование)
-
Тема не удалялась, она на месте.
Вы пытаетесь пойти по ссылке на отдельное сообщение.
;) а где это сообщение, и что , по вашему, я должен думать, если после активации ссылки получаю сообщение "Запрошенной темы не существует."?
-
Мои оценки КП высказаны при следующем способе примения: сначала абстрагируем низкоуровщину (мирясь с некоторым оверхедом относительно Си внутри реализации абстракций), а затем решаем задачи, традиционно решаемые на Си, с помощью своих абстракций (по типу абстракций Go и подобных).
"Задачи, традиционно решаемые на Си" - реализация сетевых протоколов, их клиентских и серверных частей. Например, HTTP, FastCGI.
Или реализация хранилищ данных по типу NoSQL.
-
http://forum.oberoncore.ru/viewtopic.php?f=29&t=4183
-
Мои оценки КП высказаны при следующем способе примения: сначала абстрагируем низкоуровщину (мирясь с некоторым оверхедом относительно Си внутри реализации абстракций), а затем решаем задачи, традиционно решаемые на Си, с помощью своих абстракций (по типу абстракций Go и подобных).
"Задачи, традиционно решаемые на Си" - реализация сетевых протоколов, их клиентских и серверных частей. Например, HTTP, FastCGI.
Или реализация хранилищ данных по типу NoSQL.
то есть - речь идет о самопале?
-
Что Вы имеете в виду под "самопалом"?
-
Что Вы имеете в виду под "самопалом"?
Задача изолированная (либо взаимодействие с внешним окружением ограничено, либо эффектами взаимодействия пренебрегается), 90% кода свои ( самопальные - не применяются сторонние реализации алгоритмов и компонент)
-
Лично я использую в качестве аналога сишного size_t (для позиций, длин и проч.) уже пару лет как только LONGINT. Ибо придерживаюсь в своём коде "64-bit-ready".
Это конечно здорово, но в Обероне нет типа LONGINT, единственный кандидат на эту роль - LONGREAL.
-
...
Я конечно зануда, но я не поленился, и проверил. Вначале я сходил в доку по КП (cюда: http://plas.fit.qut.edu.au/gpcp/LanguageReport.aspx#Type ), выяснил, что char он таки 16ти битный в КП (вне зависимости от реализации), а байт это натурально sint8. И тут то у меня и закрались подозрения.
....
Много слов - но суть сводится к тому, что КП - (точнее его ББ - реализация), плохо подходит для низкоуровневого программирования (точнее его задач)
Для низкоуровневого подходит хорошо как раз (почти все программы на нем писаны в низкоуровневом стиле), а вот для близкого к железу программирования (хоть высокоуровневого, хоть низкоуровневого) КП подходит плохо, а Оберон, похоже, подходит не больше чем какой-нибудь js.
-
in CP, for unsigned int(8,16), just use MOD operator:
uint8 := x MOD 256;
uint16 := x MOD 65536;
Thanks.
-
Да, почти верно.
Сторонние библиотеки вполне могут применяться, но только абстрагированным образом. Когда сделан свой абстрактный ООП-интерфейс, который пока можно гонять через одну или другую внешнюю библиотеку, а потом переписать.
Например, когда я перешёл недавно с глючного OpenSSL на PolarSSL - для проектов это оказалось незаметно. Разве что исчезли периодические загадочные исключения в дебрях OpenSSL :)
Вообще, если только проект не совсем миниатюрный и кратковременный, я никогда не буду работать со сторонними компонентами напрямую, без изоляции. Исключением может стать только что-нибудь... например, типа OpenGL, если возможности такой большой библиотеки используются "по-полной". Ну или, пока что, HTML/CSS - сделать свой уровень абстракции пока ещё слабо :) :)
-
Да, почти верно.
Сторонние библиотеки вполне могут применяться, но только абстрагированным образом. Когда сделан свой абстрактный ООП-интерфейс, который пока можно гонять через одну или другую внешнюю библиотеку, а потом переписать.
То есть ты предпочитаешь писать толстые биндинги вместо тонких?
Вообще, если только проект не совсем миниатюрный и кратковременный, я никогда не буду работать со сторонними компонентами напрямую, без изоляции.
Под изоляцией видимо подразумевается не реальная изоляция (изолирующая от неконтроллируемого падения из за ошибки в стороннем компоненте), а просто толстый биндинг?
Исключением может стать только что-нибудь... например, типа OpenGL, если возможности такой большой библиотеки используются "по-полной". Ну или, пока что, HTML/CSS - сделать свой уровень абстракции пока ещё слабо :) :)
Ну, самое интересное в общем то быстро руками не написать, поэтому от биндингов к сторонним либам никуда не деться. Скажем OpenCV, или там x264 ну и вообще ffmpeg. Ну и работа с видеокамерой тоже.
PS. Тонкий биндинг - это просто вытаскиваения в используемый ЯП полного API нужной библиотеки как есть (ну с поправкой на специфику языка).
Толстый биндинг - это оборачивание API нужной библиотеки в собственные абстракции родственные стилю программирования на данном языке.
Тонкий биндинг может быть сгенерирован автоматически и обычно не содержит оверхеда (либо он минимален). Толстый биндинг всегда пишется и поддерживается вручную и непременно имеет оверхед.
-
Да, почти верно.
....
Хорошо.. теперь Алексей - на сцену свое видение (возможно, с претензиями - но не к словам Ильи , а к ЯП) вопроса.
-
Да, я всегда использую толстые биндинги, при этом обычно вообще отвязанные от специфики конкретной либы (ибо я видел очень мало чужих либ, абстракции которых мне бы нравились; либо бывает, что абстракций нет вообще, только болты и гайки).
-
Да, я всегда использую толстые биндинги, при этом обычно вообще отвязанные от специфики конкретной либы (ибо я видел очень мало чужих либ, абстракции которых мне бы нравились; либо бывает, что абстракций нет вообще, только болты и гайки).
было бы удивительно увидеть обратное, если работаете над изолированными самодостаточными проблемами, которые не имеют МАССОВОГО потребителя и конкурентов...
-
PROCEDURE SignedToUnsigned (x: BYTE): INTEGER;
VAR ch: CHAR;
BEGIN
ch := CHR(x);
RETURN ORD(BITS(ORD(ch)) * {0,1,2,3,4,5,6,7});
END SignedToUnsigned;
Ну зачем такие извращения, господа знатоки Оберонов. Пишите так:
PROCEDURE SignedToUnsigned (x: BYTE): INTEGER;
BEGIN
RETURN x MOD 100H;
END SignedToUnsigned;
И тогда всё хорошо.
-
Это конечно здорово, но в Обероне нет типа LONGINT, единственный кандидат на эту роль - LONGREAL.
Ну здрасьте, как это нет. Вы какую реализацию Оберона имеете ввиду? Например, смотрите это описание языка Оберон-2 (http://www.uni-vologda.ac.ru/oberon/o2rus.htm).
Удобный и простой набор базовых типов (символы и строки, короткие и длинные целые и вещественные, логический тип, множества, процедурный тип)
Простые и удобные правила совместимости числовых типов (SHORTINT<=INTEGER<=LONGINT<=REAL<=LONGREAL)
Как работать с памятью выше 2-х гигабайт, не имея беззнаковых целых? В А2 не смогли, поэтому решили таки эти беззнаковые там реализовать. Как обработать файл, размером больше 2-х гб, не вводя 64-х битное знаковое целое там, где оно совершенно не нужно?
Разрешите и мне добавить свои пять копеек.
Мы, воспитанные на ТурбоПаскале и Си привыкли к зоопарку знаковых и беззнаковых типов, поэтому в первом приближении Оберон кажется ущербным. Однако задумаемся вот о чём. Засилье беззнаковых типов разного размера, приравненных в возможностях к знаковым, естественно ведёт к их широкому использованию не только в системных задачах. Беззнаковыми делаются координаты, индексы и прочее. Это перетекает в API многих ОС и прикладных и системных библиотек. Появляется необходимость в приведении типов — знаковых к беззнаковым и наоборот (как правило без возбуждения исключения при неудаче), таким образом, зоопарк типов ведёт к концептуальной путанице прикладного кода и необходимости приводить типы в прикладных задачах, расставляя самому же себе мины на будущее и настоящее. Что ложится дополнительным бременем на бедные мозги программистов.
Раньше на старых процессорах (8 и 16-битных) беззнаковые вычисления были несколько более оптимальны, поэтому типы такие вводились без всякой альтернативы. Сейчас же я вижу их равноправное со знаковыми использование в прикладных задачах излишним. Особенно с учётом того, что программы всё сложнее, и количество вещей, которые необходимо держать в голове, всё больше. Здесь надо смещать акценты в сторону упора на числа вообще, а не их подмножества, которые когда-то эффективнее использовалось на 8 и 16 битных процессорах.
Оберон предлагает путь добровольного аскетизма, получения в уединении и молитве мистических способностей. Естественно этот путь не предлагается всем. Но что Оберон может предложить сейчас?
Если уж есть желание иметь массив размером > 2 Gb, но непременно меньше 4 Gb, и адресовать его обязательно 32-битной переменной, то индексы можно задавать так:
VAR i: INTEGER; (* Этот INTEGER 32 бит. *)
...
arr[LONG(i) MOD 100000000H]
Никто не будет спорить с тем, что хороший компилятор может оптимизировать это выражение, даже не переходя в область 64 бит.
В системных задачах часто есть потребность адресовать что-либо. И хотя при такой адресации при очередном INC(addr) вполне может быть достигнут переход от MAX(INTEGER) к MIN(INTEGER) на практике это обычно всё равно работает, ибо отслеживание таких исключений как правило выключено. Вроде хорошо, пользоваться можно, но хочется идеологической правильности. Как же быть?
Прикладной уровень не требует зоопарка целых типов, особенно коротких. Вы не задумывались над тем как проблема с типами лихо решена в .NET и JVM? Эти платформы просто зафиксировали размер типов. А у Оберонов, видите ли, размер INTEGER плавает от реализации к реализации ещё с времён Lilith, с 16 и до 32 бит. Стандартом размер INTEGER не оговорен. Но недостаток ли это? Да, ещё остаются реализации Оберона с 16-битным INTEGER даже на архитектуре x86, но, по идее, этот тип должен быть базовой разрядностью платформы и предлагаться для максимального употребления в прикладной части, чтобы не было засилья LONGINT как в исходниках AOS. И необходимости привлекать для 64 бит новый тип HUGEINT. Использование 16-битного INTEGER на современных платформах не несёт никакого преимущества ни в размере кода, ни в его быстродействии, а тем паче в точности вычислений.
А вы рылись в сишном коде, в котором на каждом шагу знаковые и беззнаковые перемешаны и кастятся друг в друга (иногда неявно)? Про надёжность и высокую понимаемость такого кода говорить не приходится, поэтому чтобы оградить Оберон от такого и были хирургически убраны беззнаковые типы. Но потребность в них для системного программирования всё равно есть. И поэтому я вижу решение в том, чтобы просто ограничить их использование. Я за внесение беззнаковых типов в псевдомодуль SYSTEM. Так мы получим эффективную адресацию в системных задачах без риска поймать исключение при от MAX(INTEGER) к MIN(INTEGER). И так мы запретим огульное использование системы беззнаковых типов где попало и как попало. Такое расширение я реализовал в доработанном мною трансляторе Оберона-2 в Си Ofront. Но то, что находится внутри SYSTEM – это нестандартная языковая надстройка, решение как её реализовать ложится на разработчиков компилятора. Что к стандартам Оберон-языков отношения не имеет.
-
Это конечно здорово, но в Обероне нет типа LONGINT, единственный кандидат на эту роль - LONGREAL.
Ну здрасьте, как это нет.
Привет.
Вы какую реализацию Оберона имеете ввиду? Например, смотрите это описание языка Оберон-2 (http://www.uni-vologda.ac.ru/oberon/o2rus.htm).
Я не имею ввиду какую-либо конкретную реализацию Оберона. Я имею ввиду ровно то, что написано в топике. Прочитай внимательно название топика, и скажи, при чем тут Оберон-2?
-
Я не имею ввиду какую-либо конкретную реализацию Оберона. Я имею ввиду ровно то, что написано в топике. Прочитай внимательно название топика, и скажи, при чем тут Оберон-2?
Ах ё. Здесь в ветке активно подвергается гонениям именно Оберон-07 и его все недостачи, но циферка 07 практически не упоминается нигде, кроме топика. Что же могут подумать люди далёкие от Оберонов, читая такие комментарии? И вот уж не думал, что О-07 так активно используется как альтернатива Оберону-2 и КП в программировании для больших компьютеров.
Но неужели в Обероне-07 нет типа LONGINT? Я слышал, в последней редакции документа мэтр таки вытащил из SYSTEM на свет божий даже тип BYTE.
Хорошо, я поправлюсь. Критикуйте себе на здоровье Оберон-07 по полной, ибо он того заслуживает.
P.S. Мы кажется на "ты" не переходили?
-
Я не имею ввиду какую-либо конкретную реализацию Оберона. Я имею ввиду ровно то, что написано в топике. Прочитай внимательно название топика, и скажи, при чем тут Оберон-2?
Ах ё. Здесь в ветке активно подвергается гонениям именно Оберон-07 и его все недостачи, но циферка 07 практически не упоминается нигде, кроме топика. Что же могут подумать люди далёкие от Оберонов, читая такие комментарии?
Эмм.. Не знаю что они могут подумать, но было бы странно в каждом коментарии уточнять что речь идет о последней версии Виртовского Оберона (за 2012 год Вирт его так и не зарелизил, только черновик info21 выслал помнится). Версия оберона специально была вынесена аж в заголовок обсуждения. Чтобы как раз таких вот недоразумений не было.
И вот уж не думал, что О-07 так активно используется как альтернатива Оберону-2 и КП в программировании для больших компьютеров.
Оберон никогда не позиционировался Виртом как решение исключительно для микроконтроллеров. В том числе и новейшие его версии. Оберон-2->КП это ответвление от Виртовских оберонов все же (родоначальник ответвления, сколь я помню - Object Oberon). И вирт активного участия в этой побочной ветке не принимает.
Но неужели в Обероне-07 нет типа LONGINT? Я слышал, в последней редакции документа мэтр таки вытащил из SYSTEM на свет божий даже тип BYTE.
Нету. Более того - типа BYTE там тоже нету. Даже в SYSTEM'e. В драфте от 2012 года BYTE упоминается, но этот драфт весьма сырой. См. обсуждение (http://oberspace.dyndns.org/index.php/topic,296.0.html).
P.S. Мы кажется на "ты" не переходили?
Эмм.. Извиняюсь, если как-то этим задел, но у нас принято на "ты", по крайней мере это не считается оскорблением/панибратством. Вроде как это распространенная практика.
-
VAR i: INTEGER; (* Этот INTEGER 32 бит. *)
...
arr[LONG(i) MOD 100000000H]
А константа 100000000H в вашем примере разве не вызовет переполнение?
Если не вызовет, то какой она имеет тип?
(Как я понял, код вы привели на Обероне-2)
-
А константа 100000000H в вашем примере разве не вызовет переполнение?
Если не вызовет, то какой она имеет тип?
(Как я понял, код вы привели на Обероне-2)
Тип LONGINT. Это "правильный" Оберон — Компонентный Паскаль. Такой код будет работать в BlackBox и GPCP.
-
А константа 100000000H в вашем примере разве не вызовет переполнение?
Если не вызовет, то какой она имеет тип?
(Как я понял, код вы привели на Обероне-2)
Тип LONGINT. Это "правильный" Оберон — Компонентный Паскаль. Такой код будет работать в BlackBox и GPCP.
Тогда нет вопросов. Но есть одна маленькая поправочка. Следовало использовать суффикс "L":
The suffix 'H' is used to specify 32-bit constants in the range -2147483648 .. 2147483647. At most 8
significant hex digits are allowed. The suffix 'L' is used to specify 64-bit constants.
-
А константа 100000000H в вашем примере разве не вызовет переполнение?
Если не вызовет, то какой она имеет тип?
(Как я понял, код вы привели на Обероне-2)
Тип LONGINT. Это "правильный" Оберон — Компонентный Паскаль.
Главное это не говорить Вирту :-)
-
Да, верно.
-
Да, верно.
Вы про суффикс "L" или про то, что лучше Вирту не говорить?
-
Я настолько редко использую LONGINT числа, что забыл о суффиксе L напрочь. Погодите, а ведь в AO такой суффикс кажется не применяется?
Ну а про Вирта. Не забывайте, что профессор уже немолод.
Мне было бы интересно услышать какими достоинствами на практике обладает Оберон-07 перед Обероном-2/КП, даже для микроконтроллеров, даже если не брать во внимание такой разброс и шатания в ревизиях.
-
Мне было бы интересно услышать какими достоинствами на практике обладает Оберон-07 перед Обероном-2/КП, даже для микроконтроллеров, даже если не брать во внимание такой разброс и шатания в ревизиях.
Тем единственным достоинством, что это официальный Оберон. Остальные "обероны" к Вирту отношения не имеют...
-
Ну, это не такое уж большое достоинство. Переживём.
Ребёнку в 4 годика покупают штаники и ждут хорошего поведения в садике. А в 10 хороших отметок в школе. Оберон тоже растёт, ему пора слазить из рук дедушки. Ничего удивительного, процесс естествен.
-
2Oleg N. Cher:
Ничего не имею против Вирта, и дай Бог ему здоровья. Но мне не даёт покоя ваш пример: http://oberspace.dyndns.org/index.php/topic,398.msg11929.html#msg11929 (http://oberspace.dyndns.org/index.php/topic,398.msg11929.html#msg11929)
Я так и не понял одобряете ли вы использование в нём суффикса "L".
Если не одобряете, то код работать не будет. Если же одобряете, то я тогда готов предложить более простой вариант, который хоть и использует 64 бит, но при этом равносилен вашему, с учётом замены "H" на "L":
VAR i: LONGINT; (* Это INTEGER 64 бит. *)
PS: Не совсем понял при чём тут АО, ведь вы говорили про "правильный Оберон" - КП.
-
Точнее:
VAR i: LONGINT; (* Это INTEGER 64 бит. *)
...
arr[i]
-
2Oleg N. Cher:
Ничего не имею против Вирта, и дай Бог ему здоровья. Но мне не даёт покоя ваш пример: http://oberspace.dyndns.org/index.php/topic,398.msg11929.html#msg11929 (http://oberspace.dyndns.org/index.php/topic,398.msg11929.html#msg11929)
Я так и не понял одобряете ли вы использование в нём суффикса "L".
Одобряю конечно. Просто подымался вопрос: как индексировать с помощью 32-битной переменной массивы, для индексации которых не хватает разрядности знакового целого 32 бита. Вот и был предложен вариант для КП, который теоретически правилен, хотя может и не совсем эффективно компилироваться (из-за приведения к 64 бит).
Ну а если говорить о том, как эта задача решается в Обероне-07, то тут я пас.
-
Единственный выход который я вижу, использовать LONGREAL (и надяеться что во всех реализациях этого Оберона LONGREAL будет хотя бы 64битным).
А если реализация для 16-битной системы? ;) На все расчитывать не стоит. А в конкретной может быть какой-нибудь SYSTEM.UINT32.
-
Таки я нашел ответ на свой вопрос - почему Вирт выпилил беззнаковые целые в "Краткой истории Modula и Lilith"
Тип CARDINAL
Как можно объяснить введение типа CARDINAL — типа натуральных чисел — в виде еще одного базового типа? Потребность эта возникла из желания представлять адреса как числовые типы.
Lilith была 16-разрядной машиной с памятью 216 слов, поэтому нельзя было позволить себе такую роскошь, как наличие бесполезного бита знака. На первых порах после ввода этого типа все выглядело благополучно, но затем возникло несколько проблем. Как, например, можно эффективно реализовать сравнение i < c? Вопрос это легко снять, если смешанные выражения запрещены.
Для целочисленной (знаковой) и натуральной (беззнаковой) арифметики требуются два разных набора инструкций. Даже если одна и та же инструкция может использоваться для сложения, все равно существует различие в определении переполнения. Для деления ситуация еще более проблематична. В математике частное q = x DIV y и остаток r = x MOD y определяются отношениями
x = q * y + r, 0 <= r < y
Целочисленное деление в противоположность вещественному асимметрично в отношении 0.
Например,
10 DIV 3 = 3 10 MOD 3 = 1
-10 DIV 3 = 4 -10 MOD 3 = 2
Большинство компьютеров, однако, предоставляет инструкции, которые неверны в отношении данного определения. Они трактуют целочисленное деление наподобие вещественного деления, симметричного относительно 0:
(-x) DIV y = -(x DIV y)
(-x) MOD y = -(x MOD y)
Если целочисленное деление реализуется корректно, то деление на число в степени двойки может быть реализовано более эффективно путем простых сдвигов. В случае неверных инструкций деления это невозможно:
x*2n = left(x,n)
x DIV 2n = right(x,n)
Следующие процессоры помимо прочего осуществляют целочисленное деление вопреки математическому определению: Motorola 680x0, Intel 80x86, Intel 80960, DEC VAX, IBM Power.
Хуже того, язык Ada возвел эту ошибку в ранг стандарта.
Дабы не вступать в противоречие с другими, мы решили принять неверную арифметику.
Оглядываясь назад, можно с уверенностью сказать, что это было, конечно, серьезной ошибкой.
Компилятор использовал инструкции сдвига для умножения и деления чисел в степенях двойки только в случае выражений типа CARDINAL.
В общем и целом введение типа CARDINAL объясняется необходимостью обработки 16-разрядных адресов. С точки зрения математиков (которые изобрели отрицательные числа ради алгебраической полноты) его следовало бы назвать шагом назад, так как он создавал новые сложности для программиста, которых до этого не было. Рассмотрим, к примеру, следующие операторы, выполняющие действие Q для x = N-1, ..., 1, 0:
x := N-1;
WHILE x >= 0 DO Q; x := x-1 END
Если "x" типа INTEGER, то программа корректна, но если "x" типа CARDINAL, то такая запись приводит к переполнению, которого можно избежать путем корректной альтернативной формулировки
x := N;
WHILE x > 0 DO x := x-1; Q END
Приход 6 лет спустя 32-разрядных компьютеров дал возможность забыть тип CARDINAL. Этот эпизод показал, насколько неадекватность аппаратуры может заставить разработчика языка идти по пути усложнений и компромиссов, если тот хочет в полной мере использовать доступные аппаратные возможности. Урок состоит еще и в том, что память размером 2n требует
целочисленной арифметики как минимум с (n+1) разрядом.
-
Целочисленное деление в противоположность вещественному асимметрично в отношении 0.
Например,
10 DIV 3 = 3 10 MOD 3 = 1
-10 DIV 3 = 4 -10 MOD 3 = 2
Большинство компьютеров, однако, предоставляет инструкции, которые неверны в отношении данного определения. Они трактуют целочисленное деление наподобие вещественного деления, симметричного относительно 0:
(-x) DIV y = -(x DIV y)
(-x) MOD y = -(x MOD y)
Если целочисленное деление реализуется корректно, то деление на число в степени двойки может быть реализовано более эффективно путем простых сдвигов. В случае неверных инструкций деления это невозможно:
x*2n = left(x,n)
x DIV 2n = right(x,n)
Следующие процессоры помимо прочего осуществляют целочисленное деление вопреки математическому определению: Motorola 680x0, Intel 80x86, Intel 80960, DEC VAX, IBM Power.
Хуже того, язык Ada возвел эту ошибку в ранг стандарта.
В Аде есть две операции вычисления остатка от деления -- rem (остаток от деления, округляющего к нулю) и mod (остаток от деления, округляющего к -Inf).
Но операция деления только одна -- округляющая к нулю.
А вот в Хаскелле есть два набора quot и rem (округляют к нулю) и div и mod (округляют к -Inf):
(x `quot` y)*y + (x `rem` y) == x
(x `div` y)*y + (x `mod` y) == x
10 `divMod` 3 == ( 3, 1) 10 `quotRem` 3 == ( 3, 1)
(-10) `divMod` 3 == (-4, 2) (-10) `quotRem` 3 == (-3, -1)
( -9) `divMod` 12 == (-1, 3) ( -9) `quotRem` 12 == ( 0, -9)
-
Сильно натянутые причины для исключения беззнаковых целых. Не удивлюсь, если и диапазоны он выпилил по сходным же причинам, типа вдруг кто-нибудь забудет что это диапазон
-
Сильно натянутые причины для исключения беззнаковых целых. Не удивлюсь, если и диапазоны он выпилил по сходным же причинам, типа вдруг кто-нибудь забудет что это диапазон
возможно, а может быть просто по тому, что в реальных оберонных задачах (лежащих в области эффективного решения с помощью Оберона - в его понимании) возможностей напомнить об этом компилятором не очень много.
-
Таки я нашел ответ на свой вопрос - почему Вирт выпилил беззнаковые целые в "Краткой истории Modula и Lilith"
Kemet, большое спасибо! Очень ценная инфа.
-
Большинство компьютеров, однако, предоставляет инструкции, которые неверны в отношении данного определения. Они трактуют целочисленное деление наподобие вещественного деления, симметричного относительно 0:
(-x) DIV y = -(x DIV y)
(-x) MOD y = -(x MOD y)
Если целочисленное деление реализуется корректно, то деление на число в степени двойки может быть реализовано более эффективно путем простых сдвигов. В случае неверных инструкций деления это невозможно:
x*2n = left(x,n)
x DIV 2n = right(x,n)
Следующие процессоры помимо прочего осуществляют целочисленное деление вопреки математическому определению: Motorola 680x0, Intel 80x86, Intel 80960, DEC VAX, IBM Power.
А я блин голову ломал почему оно так :)