MSElang : обсуждение фишек

[Mikhail]

А сейчас будто мы сильно чем-то управляем?

Да. Я могу сам замапить любой тип явно, а не подстраиваться под какой-либо алгоритм зашитый в компилятор.

[alexey38]

Насчет целочисленных типов. При разработке некоторого приложения, решающего конкретную задачу бывает три варианта:

Вариант 1. Нужен счетчик цикла, который в конкретной задаче не превысит даже 1000. Тип нужен адаптированный под конкретный процессор, чтобы работал максимально быстро. На 16 битных - это 16 бит, на 32 битных - это 32 бита, на 64 битных либо 32, либо 64. То есть разрядность определяется оптимизацией под конкретную платформу.

Вариант 2. Делается некоторая структура данных (record, array), которую в блочном виде считываем из файла, или получаем по сети. В этом случае нужно, чтобы тип был строго конкретной размерности, ни как не завися от процессора и платформы.

Вариант 3. Решается некоторая задача, в которой известно, что численные переменные могут быть в некотором диапазоне. Например, могут быть сотни миллиардов, тут нужен не меньше, чем int64. А если сотни миллионов, то достаточно int32. Тут оптимизация под конкретную платформу должна работать только в сторону увеличения разрядности. Если нам достаточно int16, но работать быстрее будет int64 на конкретном процессоре, то должно быть int64. Если нам нужно int64, то даже на 16-битном процессоре нужно реализовывать int64, как бы сложно это не было.

Итого: чтобы язык был пригодным к реальному использованию в нем должно быть реализованы все три варианта. Если какой-то из вариантов невозможно будет реализовать, то такой язык обречен. На нем никто не будет писать серьезные проекты, т.к. начиная проект я никогда не могу знать, какие мне потребуются типы через 5 лет разработки. Поэтому я никогда не буду даже смотреть язык, который потенциально препятствует завершению проекта в будущем.

Добавлено спустя 3 минуты 15 секунд:
Дополнение для варианта 2. В идеале нужно указывать не только разрядность в битах, но и очередность следования байт в слове.

[Mikhail]

В идеале нужно указывать не только разрядность в битах, но и очередность следования байт в слове.

Зачем? Надо работать с аппаратно поддерживаемыми типами и эмулировать, при необходимости, "длинные" целые, тем более что арифметические операции с учетом бита переноса, как правило, реализованы аппаратно. Реализация эмуляции вещественной арифметики вопрос спорный, скорее всего нужно.

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

[debi12345]

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

Ага В С это делается туевой хучей DEFINE-макросов.

[MiniQ]

Вот 4 страницу читаю, и думаю: Вирт всю жизнь занимался разработкой идеального языка программирования, ну почему бы не взять на вооружение его труды? Возьмите Оберон за базу.

[Лекс Айрин]

В С это делается туевой хучей DEFINE-макросов.

и это язык высокого уровня... на ассемблере это несколько операторов...

[Mikhail]

Вот 4 страницу читаю, и думаю: Вирт всю жизнь занимался разработкой идеального языка программирования, ну почему бы не взять на вооружение его труды? Возьмите Оберон за базу.

Я уже предлагал. Можно взять модулу-2 (3) или оберон. Пакеты из явы можно позаимствовать.

[debi12345]

и это язык высокого уровня... на ассемблере это несколько операторов...

Задача С в этом случае - избежать написания функции (фрэйм вызова которой медленнее чем сами вычисления), нечто типа :

Код: Выделить всё

#define SWAP_BYTES(A)  (A << 8)||(A >> 8)

это будет скомпилирвано в реально несколько операторов на ассемблере.

[mse]

I have already suggested it. You can take a Modula-2 (3) or Oberon.

How can one define a 16bit unsigned integer type in Oberon?

[Лекс Айрин]

Задача С в этом случае - избежать написания функции (фрэйм вызова которой медленнее чем сами вычисления), нечто типа :

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

[alexey38]

Зачем? Надо работать с аппаратно поддерживаемыми типами и эмулировать, при необходимости, "длинные" целые, тем более что арифметические операции с учетом бита переноса, как правило, реализованы аппаратно. Реализация эмуляции вещественной арифметики вопрос спорный, скорее всего нужно.
Порядок не нужно указывать, если порядок слов из внешнего источника отличается, то перед использованием необходимо произвести конвертацию во внутреннее представление, а перед передачей конвертировать вновь.

Зачем? Чтобы делать кросс-платформенные приложения, где кросс-платформенность это не просто Винь и Линь, а реально разные платформы на разных и несовместимых друг с другом процессорах.

Итак есть некий файл в заранее известном формате, или есть некий поток по сети (или из порта ввода/вывода) в заранее известном формате. Но в кросс-платформенном варианте мы изначально не знаем характеристик своего процессора, мы не знаем в каком он порядке хранит байты для 16, 32 и 64 разрядных слов. Например, на интеловском проце тип int64le будет равен int64, а int64be при любых операциях будет автоматически выполнять перевертыши. На мотороловском проце все будет наоборот. Но код на языке программирования будет один и тот же.

Добавлено спустя 8 минут 58 секунд:

Насчет целочисленных типов. При разработке некоторого приложения, решающего конкретную задачу бывает три варианта:
Вариант 1. Нужен счетчик цикла, который в конкретной задаче не превысит даже 1000. Тип нужен адаптированный под конкретный процессор, чтобы работал максимально быстро. На 16 битных - это 16 бит, на 32 битных - это 32 бита, на 64 битных либо 32, либо 64. То есть разрядность определяется оптимизацией под конкретную платформу.
Вариант 2. Делается некоторая структура данных (record, array), которую в блочном виде считываем из файла, или получаем по сети. В этом случае нужно, чтобы тип был строго конкретной размерности, ни как не завися от процессора и платформы.
Вариант 3. Решается некоторая задача, в которой известно, что численные переменные могут быть в некотором диапазоне. Например, могут быть сотни миллиардов, тут нужен не меньше, чем int64. А если сотни миллионов, то достаточно int32. Тут оптимизация под конкретную платформу должна работать только в сторону увеличения разрядности. Если нам достаточно int16, но работать быстрее будет int64 на конкретном процессоре, то должно быть int64. Если нам нужно int64, то даже на 16-битном процессоре нужно реализовывать int64, как бы сложно это не было.
Итого: чтобы язык был пригодным к реальному использованию в нем должно быть реализованы все три варианта. Если какой-то из вариантов невозможно будет реализовать, то такой язык обречен. На нем никто не будет писать серьезные проекты, т.к. начиная проект я никогда не могу знать, какие мне потребуются типы через 5 лет разработки. Поэтому я никогда не буду даже смотреть язык, который потенциально препятствует завершению проекта в будущем.
Добавлено спустя 3 минуты 15 секунд:
Дополнение для варианта 2. В идеале нужно указывать не только разрядность в битах, но и очередность следования байт в слове.

Итого мое предложение следующее:
Для варианта 1: integer,uinteger - где фактическая размерность переменной зависит от конкретного CPU (минимум 16), опитмизация на быстродействие.
Для варианта 2: int8,uint8,int16be,int16le,uint16be,uint16le,int32be,int32le,uint32be,uint32le,int64be,int64le,uint64be,uint64le - строгий размер и конкретная очередность байт
Для варианта 3: integer(32),uinteger(32),integer(64),uinteger(64) - где 32 или 64 - это минимальная точность, т.е. вариант 1 - это integer(16),uinteger(16).

Итого имеем некую лаконичность и принцип наименования типа, если в будущем потребуется делать например 128 битные числа, то синтаксис уже определен.

Добавлено спустя 3 минуты 55 секунд:
Лаконичность в том, что есть всего два зарезервированных слова: integer, int
один префикс: u
несколько суффиксов: 8, 16, 32, le, be, (32), (64).

[Mikhail]

How can one define a 16bit unsigned integer type in Oberon?

Оберонов много разных. В "классическом" Обероне нет беззнаковых типов.
Целых - 3 типа: ShortInt, Integer, LongInt. Причем sizeOf(ShortInt)<=sizeOf(Integer)<=sizeOf(LongInt).
Размер базового типа (Integer) зависит от платформы.

Но есть специальный модуль System при подключении которого можно все.
Подробнее здесь http://store.oberoncore.ru/lib/book/report_oberon.pdf

Я предлагаю Оберон (Модулу) взять за прототип, а не копировать полностью.

Добавлено спустя 11 минут 26 секунд:

Итак есть некий файл в заранее известном формате, или есть некий поток по сети (или из порта ввода/вывода) в заранее известном формате. Но в кросс-платформенном варианте мы изначально не знаем характеристик своего процессора, мы не знаем в каком он порядке хранит байты для 16, 32 и 64 разрядных слов. Например, на интеловском проце тип int64le будет равен int64, а int64be при любых операциях будет автоматически выполнять перевертыши. На мотороловском проце все будет наоборот. Но код на языке программирования будет один и тот же.

Для каждой платформы (платформа это, грубо, CPU + ОС) свой вариант библиотеки. Конвертацию нужно делать на входе в библиотеку и на выходе. Делать ее перед каждой арифметической операцией это огромный overhead.

[mse]

I read a newer Oberon Report from 2013-10-1 but could not find out how to define the wanted sized types.
http://www.inf.ethz.ch/personal/wirth/A ... Report.pdf

[Mikhail]

I read a newer Oberon Report from 2013-10-1 but could not find out how to define the wanted sized types.

Это другой Оберон.
Там указан только размер (неявно) для типа byte. Тип Integer зависит от платформы (разрядность CPU).

[mse]

If I understand correct you write: "Why discussing the types of MSElang? Better use the Oberon type system, Niklaus Wirth used a whole life to design the best programming language".
But Oberon doesn't allow to define an integer type of fixed size which in my opinion is important especially for programming of microcontrollers?