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

[Mikhail]

хотя занимает совсем мало инструкций. Но на молочении даже это "совсем мало" заметно.

зато тут есть лишняя команда сравнения

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

cmpl   $-1,%esi

А вообще это здесь оффтоп, я думаю.

[debi12345]

А вообще это здесь оффтоп, я думаю.

Ну почему же ? Оценка цены проверки диапазона если таковую реализовать в рантайме для типов вроде "integer from 0 to 10" или integer{5}. Если задаешь точный диапазон, то подразумевается что будешь его проверять не только на этапе компиляции

[alexey38]

Алексей, умоляю, больше не пишите мне.

Михаил, если Вы сами не умеете программировать, если у Вас проблемы с математикой, если у Вас проблемы с логикой, если Вы не знаете значений таких слов как "сущность", то зачем Вы пишите на этом форуме?

Есть такие прекрасные профессии, как дворник, портной, повар. Это для Вас будет лучшим выбором.

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

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

Оценка цены проверки диапазона если таковую реализовать в рантайме для типов вроде "integer from 0 to 10" или integer{5}. Если задаешь точный диапазон, то подразумевается что будешь его проверять не только на этапе компиляции

Мне кажется, что оценка на вхождение в диапазон, как на этапе компиляции, так в runtime, если и нужна, то очень и очень редко. Я сходу не вспомнил задач, где такое бы требовалось. Если знаете, то расскажите. Такое бывает нужно при вводе, то тогда при выходе нужно генерировать не исключение, а предупреждение для пользователя. Иногда нужно проверять результат вычисления, но опять же нужно не исключение, а выдача сообщений, ранжированных исходя из полученных значений.

Добавлено спустя 27 минут 3 секунды:
Если обобщить разговоры про целочисленные типы, то никто не смог опровергнуть предложение (разных авторов), которое можно сформулировать следующим образом:
- есть один целочисленный тип - int или integer (это уже на вкус, мне лично нравится более краткий int).
- к этому целочисленному типу можно применять несколько модификаторов:
- признак беззнаковости (по умолчанию знаковый);
- признак минимальной разрядности, указанный в битах (по умолчанию выбирается оптимальный под конкретную платформу), если указана разрядность отличающаяся от 16, 32, 64, 128, то либо компилятор дает ошибку, либо сам округляет вверх до ближайшего (17 округлит до 32).
- признак фиксирования размера переменной (8, 16, 32, 64), и порядка чередования байтов (BE, LE), что требуется только для описания блоков данных при выполнении ввода/вывода (файл, порт, сеть).
- естественно, что при операциях с целочисленными переменными имеющими разные модификаторы, компилятор будет генерировать дополнительный машинный код для преобразования типов, но для программиста ничего не нужно писать вручную.

С позиции программиста, мы имеем одну сущность (целочисленная переменная), которая имеет вариации по внутренней реализации. Я предполагаю, что в 95% кода будет использоваться только int и int32. Все остальные модифицированные типы нужны, но используются редко, поэтому никакого оверхеда не будет в реальных программах.

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

Раз зашел вопрос про сущности, то достаточно бессмысленно отделять сущности самого языка и сущности базовых библиотек. С позиции чистой теории - это разные категории. Но с практической позиции, это одно и тоже. Беда практически всех современных языков (в их современной реализации, например, FPC) в том, что сам язык относительно лаконичен, но библиотеки, даже базовые - это полный кошмар, никакой общей логики, применяются совершенно разные подходы. Поэтому в данном случае имеет смысл обсудить не только базовые конструкции языка, но и базовые типы (включая строковые), и базовые библиотеки (хотя бы на уровне требований к ним, и принципа их построения).

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

[debi12345]

Мне кажется, что оценка на вхождение в диапазон, как на этапе компиляции, так в runtime, если и нужна, то очень и очень редко.

На этапе компиляции 100% нужна - сам бог велел и все компиляторы эти проверки делают. В рантайме конечно же опционально.

[mse]

Currently the plan is to define ordinal types in MSElang by range:

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

type
  thebooleantype = $ff; //8bit
  thecardinaltype = $00000000..$ffffffff; //32bit
  theintegertype = -$8000..$7fff; //16 bit
  thecharactertype = #$00..#$ff; //8bit
  thenotbyteboundarytype = $0..$f;
  //4bit if bitpacked, 8bit otherwise, helpful as bitfields in controllerregisters for
  // bitpacked records
  thesubrangetype = 5..10; //4bit if bitpacked, 8bit otherwise


The MSElang RTL will be the bare minimum, most of the functionality will be moved to the framework (for example MSEgui or Lazarus). The file extension for MSElang is ".mla".
The MSElang RTL uses the unit "systypes.mla" which defines commonly used types:

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

unit systypes;
type
//same on all architectures
  bool1= $1; //1bit
  bool8= $ff;
  bool16= $ffff;
  bool32= $ffffffff;
  card8 = $00..$ff;
  card16 = $0000..$ffff;
  card32 = $00000000..$ffffffff;
  card64 = $0000000000000000..$ffffffffffffffff;
  int8 = -$80..$70;
  int16 = -$8000..$7fff;
  int32 = -$80000000..$7fffffff;
  int64 = -$8000000000000000..$7fffffffffffffff;
  char8 = #$00..#$ff;
  char16 = #$0000..#$ffff;
  char32 = #$00000000..#$ffffffff:


//achitecture dependent, there can be more diferentation for
//different operating systems
//boolean, cardinal and integer are the "recommended" types
//card and int have the size of the CPU registers

  boolean = bool8;

{$if REGISTERSIZE = 16}
  cardinal = card16;
  integer = int16;
  card = card16;
  int = int16;
{$else}
  cardinal = card32;
  integer = int32;
{$endif}

{$if REGISTERSIZE = 32}
  card = card32;
  int = int32;
{$else}
  {$if REGISTERSIZE = 64}
  card = card64;
  int = int64;
  {$endif}
{$endif}


Please see the Wiki for thoughts about strings.
@alexey38, how would you denote big-/little-endian in type definitions?

[Mikhail]

Если задаешь точный диапазон, то подразумевается что будешь его проверять не только на этапе компиляции

Собственно переполнение контролируется только для целых равных размеру регистра, для остальных целочисленных типов, фактически вставляется код эквивалентный

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

if (xmin <= x) and (xmax >= x) then...

[debi12345]

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

Не автоматом, а на каждом доступе к контроллируемым переменным вызывается специнструкция JNO (ловящая флаг CPU о переполнении) :

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

jno <label>; // если нет переполнения операнда то продолжать на эту метку
call FPC_OVERFLOW; // сгенерировать исключение по переполнению

То есть в итерацию включется всего одна доп. команда. Как она влияет ?
Время выполнения без контроля пеереполнения= 80..90мс.
Время выполнения с контролем переполнения = 90..120мс.

Проверка вручную

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

    if (i2 > -1) and (i2 < 100000000) then

выполняется следующим кодом :

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

movl   %ebx,%eax
cmpl   $-1,%eax
jng   .Lj53
cmpl   $100000000,%eax
jnl   .Lj53


То есть 5 доп.команд на одну переменную. Время выполнения увеличивается 140..150мс.

Добавлено спустя 15 минут 39 секунд:
Кстати, вот почему разность в скорости обработки разных длин так мала :

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

movzbl   %bl,%eax; // приведение типа int8->int32
movsbl   %bl,%eax; // приведение типа int16->int32
movl    %ebx,%eax; // int32->int32 без приведения

Никаких дополнительных команд для не-Int32 типов

[Mikhail]

Не автоматом, а на каждом доступе к контроллируемым переменным вызывается специнструкция JNO (ловящая флаг CPU о переполнении) :

Я собственно это и хотел сказать.

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

В случае типов вроде byte или word флаг переполнения "не работает", проверка для них, по сути, эквивалентна "ручной" проверке.

Да, команду копирования с расширением ввели, если не ошибаюсь, в Pentium. Раньше нужно было писать примерно так

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

xor eax, eax
mov al, [x]
add ebx //второй операнд в ebx


Кстати, Delphi 7 вроде бы так и делает.

Добавлено спустя 3 минуты 45 секунд:
Интересно как с этим обстоит дело на других архитектурах, например ARM?

[debi12345]

Кстати, с этими приведениями типов контроль диапазона входных переменных на рантайме не работает, контроллируется только результат математических операций. Хмм..

[Mikhail]

Кстати, с этими приведениями типов контроль диапазона входных переменных на рантайме не работает, контроллируется только результат математических операций. Хмм..

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

var x:1..100;
readln(a);


Если я введу 101 ошибки не будет?

[debi12345]

проверка для них, по сути, эквивалентна "ручной" проверке.

Это значит что "широкая" типизация вроде "INTEGER FROM <min> [TO <max>]" имеет смысл (проверка диапазона только на этапе компиляции - как происходит сейчас), так как не приведет к падению перформанса в ран-тайме относительно нынешней реализации.

Если я введу 101 ошибки не будет?

Если в коде проги (на этапе компиляции) - ессно будет. Чтобы ловила на ран-тайме - нужно вставлять (опциональный) код проверки - он слегка замедлит прогу. Можно придумать спецфлаг для переменных, управляющий рантайм-проверками.

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

//achitecture dependent, there can be more diferentation for
//different operating systems

How about meaningful modificators (more descriptive than the current "short*" & "long*" ) as well :

integer as TINY; // shortest for arch (current "byte")
integer as COMPACT; // smth like current int16
integer as FASTEST; // smth like current int32
integer as BIG; // smth like current int64
integer as HUGE; // maximal emulated size

Might be useful for crossplatform programming.

[Mikhail]

Это значит что "широкая" типизация вроде "INTEGER FROM <min> [TO <max>]" имеет смысл (проверка диапазона только на этапе компиляции - как происходит сейчас), так как не приведет к падению перформанса в ран-тайме относительно нынешней реализации.

Это по функционалу соответствует уже существующему типу диапазону. Свое отношение к его наличию, я уже высказал.

[alexey38]

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

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

[debi12345]

Ну сгенирируется исключение, и что с ним делать

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

[Mikhail]

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

А нужны ли исключения?