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

[alexey38]

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

Согласно моего предложения, 99% кода - это вариант 1 и вариант 3, и никакого оверхеда там не будет, наоборот на конкретной платформе будет принята оптимальная размерность и оптимальная очередность байт.
И только для описания структур и временных переменных для осуществления ввода/вывода нужно указывать типы с суффиксами le, be. Нормальный программист не будет с такими типами делать ни какой арифметики, в основном это будет оператор присваивания из int32be в integer(32), и далее вся арифметика уже с integer(32). Если так переживаете за оверхед, то можно вообще запретить для таких типов любые операции, кроме оператора присваивания и оператора сравнения.

Важность этого типа в кросс-платформенных разработках принципиальная, если ввод/вывод не идет в СУБД или текстовые файлы, то без этого нормальную программу не написать. Либо весь код будет в $IFDEF, т.е. нечитаемый.

Хороший язык - это тот язык, в котором не нужно применять костыли. А $IFDEF - это и есть костыли.

[Mikhail]

Я имел в виду принципы проектирования.

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

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

Согласно моего предложения, 99% кода - это вариант 1 и вариант 3, и никакого оверхеда там не будет, наоборот на конкретной платформе будет принята оптимальная размерность и оптимальная очередность байт.
И только для описания структур и временных переменных для осуществления ввода/вывода нужно указывать типы с суффиксами le, be. Нормальный программист не будет с такими типами делать ни какой арифметики, в основном это будет оператор присваивания из int32be в integer(32), и далее вся арифметика уже с integer(32). Если так переживаете за оверхед, то можно вообще запретить для таких типов любые операции, кроме оператора присваивания и оператора сравнения.

Важность этого типа в кросс-платформенных разработках принципиальная, если ввод/вывод не идет в СУБД или текстовые файлы, то без этого нормальную программу не написать. Либо весь код будет в $IFDEF, т.е. нечитаемый.

Хороший язык - это тот язык, в котором не нужно применять костыли. А $IFDEF - это и есть костыли.

Никакие IFDEF не понадобятся. РАЗНЫЕ реализации библиотеки под разные платформы.

PS Мне кажется вы не понимаете о чем говорите.

[mse]

Oberon and the module has a special mode in which the included "system capabilities" compiler there that can do all that allows a specific platform, a direct appeal to the registers of equipment, work with any data type, location variables at fixed addresses, etc.

Can you give a link to the documentation of that functionality?

[Mikhail]

Can you give a link to the documentation of that functionality?

Здесь вариант Оберона для микроконтроллеров. http://www.astrobe.com/Oberon.htm

Ссылка на документацию. Раздел 11.1. http://www.astrobe.com/Oberon.Report.pdf

The Module SYSTEM
The optional module SYSTEM contains definitions that are necessary to program low-level operations referring directly to resources particular to a given computer and/or implementation. These include for example facilities for accessing devices that are controlled by the computer, and
perhaps facilities to break the data type compatibility rules otherwise imposed by the language definition. It is strongly recommended to restrict
their use to specific low-level modules, as such modules are inherently non-portable and not "type-safe".

Мартин, средства низкоуровнего программирования в стандарт, фактически, не входят. Зависят от платформы и разработчика компилятора.

Добавлено спустя 12 минут 24 секунды:
Пример, System для Astrobe Oberon. page 54.
http://www.astrobe.com/Oberon.Cortex-M3.pdf

[alexey38]

Никакие IFDEF не понадобятся. РАЗНЫЕ реализации библиотеки под разные платформы.

При чем здесь библиотеки? Есть бинарный файл на диске, в котором записаны, например, целые числа int32 в порядке be и другие поля. Вам нужно быстро считать весь файл в память и его обработать. Как мне поможет реализация некой библиотеки при решении конкретной и простой задачи?
Судя по всему именно Вы не понимаете о чем идет речь. Вызов неких системных функций можно индивидуально писать под каждую платформу. Но зачем такое делать для прикладного софта? Почему мой алгоритм чтения и обработки бинарного файла должен отличаться под разные платформы?

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

[Mikhail]

Есть еще предложение, отказаться от многомерных статических массивов.
То есть оставить только объявления типа

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

type TVector = array [10] of real;


[debi12345]

Хороший язык - это тот язык, в котором не нужно применять костыли. А $IFDEF - это и есть костыли.

Золотые слова

[Kemet]

В языке zonnon для уменьшения сущностей используются модификаторы размера:

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

VAR
  int   : INTEGER;
  short : INTEGER{16};
  long  : INTEGER{32}
  huge  : INTEGER{64};
  ch    : CHAR;
  ch16  : CHAR{16};


[Mikhail]

В языке zonnon для уменьшения сущностей используются модификаторы размера:

По моему число сущностей не уменьшается, или можно написать

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

var int: INTEGER(17);


[alexey38]

В языке zonnon для уменьшения сущностей используются модификаторы размера:

Согласен. Я пытаюсь предложить модификаторы размера (при его отсутствии принимается оптимальный размер для платформы), модификаторы беззнаковости (без него знак учитывается), модификаторы порядка следования байт (без них в соответствии с платформой). Тогда имеем один тип и несколько его модификаторов - и получаем всю коллекцию типов.

Мне не нравится паскалевская идея: Shortint, smallint, longword, т.е. игра слов большой и маленький, с непонятным смыслом без подглядывания в справочник.

Есть еще предложение, отказаться от многомерных статических массивов.

А чем они Вам не угодили? Например, мне нужно задать матрицу преобразования систем координат, для этого мне нужен двухмерный статический массив. Мне в моих задачах такое часто приходится использовать, т.к. я часто работаю с преобразованием систем координат. Другое дело, что их не нужно использовать там, где это не требуется. Но для математических задача - это удобный инструмент.

Можно конечно сделать типы: Vector, Matrix и т.п., но зачем? Если есть многомерный массив.

[Kemet]

В языке zonnon для уменьшения сущностей используются модификаторы размера:

По моему число сущностей не уменьшается, или можно написать

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

var int: INTEGER(17);


Очевидно, что модификаторы размерности фиксированы в реализации языка.

[alexey38]

По моему число сущностей не уменьшается, или можно написать

У Вас странная логика. Всем известно, что систематизация и иерархия упрощает понимание. В языке zonnon тип задается двумя параметрами. Сущность цифры 16 в типе INTEGER{16} и CHAR{16} - одинаковая. Сущность слова INTEGER в типах INTEGER{16} и INTEGER{64} тоже одинаковая.
Написать можно и INTEGER(17), суть понятна, но если компилятор не умеет такое делать, то он даст ошибку и предложить изменить либо на 16, либо на 32.

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

[Kemet]

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

Например, unsigned16 или unsigned{16}

[Mikhail]

А чем они Вам не угодили? Например, мне нужно задать матрицу преобразования систем координат, для этого мне нужен двухмерный статический массив. Мне в моих задачах такое часто приходится использовать, т.к. я часто работаю с преобразованием систем координат. Другое дело, что их не нужно использовать там, где это не требуется. Но для математических задача - это удобный инструмент.

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

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

У Вас странная логика. Всем известно, что систематизация и иерархия упрощает понимание. В языке zonnon тип задается двумя параметрами. Сущность цифры 16 в типе INTEGER{16} и CHAR{16} - одинаковая. Сущность слова INTEGER в типах INTEGER{16} и INTEGER{64} тоже одинаковая.
Написать можно и INTEGER(17), суть понятна, но если компилятор не умеет такое делать, то он даст ошибку и предложить изменить либо на 16, либо на 32.

Чем

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

INTEGER{16}

отличается от

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

int16

?

[Kemet]

Чем

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

INTEGER{16}

отличается от

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

int16

?

Во-первых, количеством сущностей : int, int8, int16, int32, int64, int128, против одного integer.
Во вторых, при расширении модификаторов не требуется переопределение языка.