[Oberon-07/11] Array of bytes / byte stream

[Valery Solovey]

В смысле абстракции? Самые что ни на есть реальные команды. Отсутствие этих команд в процессоре приводит к много бОльшим проблемам в случае их использования в программе, чем использования 8битного байта при 16ти битной адресации памяти (то есть когда минимальная адресуемая ячейка 16 бит).

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

Их место - в языке, их машинное представление - дело оптимизатора кода.

Точно также можно сказать, что представление байта - дело оптимизатора кода.

Что-то я не понял... Оптимизатор кода сделает в процессоре байт того размера, который прописан в исходнике? : )

[valexey_u]

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

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

И я не издеваюсь. Это реальная проблема. И актуальная архитектура. И она такова by design и это оправдано, это не архаизмы.

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

Хотя нет, байт тоже архаизм : ). Кому он нужен? Всем нужны потоки, из которых достаются данные. Сейчас-то они представлены в виде байтов, но лучше бы уж представлялись сразу в виде данных.

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

PS. У процессоров ARM есть множество преимуществ перез x86/amd64 - они меньше, энергоэффективней и так далее. Но у них есть один фейл - они с сетью работают довольно медленно. Почему? А потому, что им таки нужно выравнивать данные. Они могут работать с не выровненными, но ме-едленно, в отличае от x86. В результате tcp/ip стек и другие сетевые протоколы процессор разбирает существенно медленней (на самом деле это моя догадка - нужно перепроверить). Так что байт рулит. Но байт в этой задаче - костыль. А нужно бы решить непосредственную задачу - удобный и быстрый разбор бинарных данных/протоколов.

[valexey_u]

В смысле абстракции? Самые что ни на есть реальные команды. Отсутствие этих команд в процессоре приводит к много бОльшим проблемам в случае их использования в программе, чем использования 8битного байта при 16ти битной адресации памяти (то есть когда минимальная адресуемая ячейка 16 бит).

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

Точно также как и типы данных.

Их место - в языке, их машинное представление - дело оптимизатора кода.

Точно также можно сказать, что представление байта - дело оптимизатора кода.

Что-то я не понял... Оптимизатор кода сделает в процессоре байт того размера, который прописан в исходнике? : )

Естественно. Сказано в спеке на язык, что тип BYTE это ВСЕГДА 10 бит - так оно и будет.  Но при чем тут процессор? Процессор штука забавная, и понятием байт вообще не оперирует :-) Там все интересней.

[Geniepro]

...
Так вот - там нет и не будет чисел с плавающей точкой, и там нет и не будет умножения и деления целых чисел. Всвязи с этим предлагаю REAL, LONGREAL а также операцию умножения и деления переместить в SYSTEM! Програмно эмулировать скажем умножение чисел с плавающей точкой - жутко не эффективно (как по памяти, так и по времени, по времени оно еще и не предсказуемо, пока-пока реалтайм!).
...
И я не издеваюсь. Это реальная проблема. И актуальная архитектура. И она такова by design и это оправдано, это не архаизмы.

В этом нет никакого смысла. В таких (да и многих других) процессорах нет тех же циклов, да даже оператора IF нет -- но это же не означает, что эти конструкции языка высокого уровня надо выкинуть только потому, что они эмулируются кучей дополнительных машинных команд. ЯВУ потому и ЯВУ что 1 команда программы на ЯВУ компилируется в десятки, сотни или даже тысячи команд машинного кода.

Так что в нормальном ЯВУ (а не в ассемблере) должны быть языковые плавающая арифметика и умножение/деление целых чисел. Да даже комплексные числа -- почему бы и нет? В последних стандартах С они уже тоже есть!

[vlad]

Да даже комплексные числа -- почему бы и нет? В последних стандартах С они уже тоже есть!

Студенты, видимо, пролоббировали... Потому как лабы являются главным "потребителем" необходимости комплексных чисел в ЯП общего назначения.

[Geniepro]

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

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

[Geniepro]

Да даже комплексные числа -- почему бы и нет? В последних стандартах С они уже тоже есть!

Студенты, видимо, пролоббировали... Потому как лабы являются главным "потребителем" необходимости комплексных чисел в ЯП общего назначения.

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

[valexey_u]

...
Так вот - там нет и не будет чисел с плавающей точкой, и там нет и не будет умножения и деления целых чисел. Всвязи с этим предлагаю REAL, LONGREAL а также операцию умножения и деления переместить в SYSTEM! Програмно эмулировать скажем умножение чисел с плавающей точкой - жутко не эффективно (как по памяти, так и по времени, по времени оно еще и не предсказуемо, пока-пока реалтайм!).
...
И я не издеваюсь. Это реальная проблема. И актуальная архитектура. И она такова by design и это оправдано, это не архаизмы.

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

В плане IF'ов и циклов там все то же самое что в x86. Принципиальных отличий нет. Так что это мимо кассы.

Так что в нормальном ЯВУ (а не в ассемблере) должны быть языковые плавающая арифметика и умножение/деление целых чисел. Да даже комплексные числа -- почему бы и нет? В последних стандартах С они уже тоже есть!

В нормальном ЯВУ это все делается либой и тащить в язык это не требуется :-) А вот Си действительно нормальным языком не является, поэтому там пришлось вшить комплексные числа в язык. :-)

[valexey_u]

Между прочим, мы отклонились от изначальной темы - ужель bytestream придется делать в виде пачки integer'ов или set'ов?

[Geniepro]

В плане IF'ов и циклов там все то же самое что в x86. Принципиальных отличий нет. Так что это мимо кассы.

Разве? Вот есть, например, в x86 команда

LOOP/LOOPx   
Loop control   
(LOOPE, LOOPNE, LOOPNZ, LOOPZ) if (x && CX--) goto lbl;

Есть ли для неё аналог во всех других процессорах (ну или хотя бы самых распространённых, типа msp430, arm, MCS51 и тд?

[Geniepro]

Между прочим, мы отклонились от изначальной темы - ужель bytestream придется делать в виде пачки integer'ов или set'ов?

А bytestream вообще идиоматичен для оберонщиков? Может и не надо его делать в Обероне?

[valexey_u]

В плане IF'ов и циклов там все то же самое что в x86. Принципиальных отличий нет. Так что это мимо кассы.

Разве? Вот есть, например, в x86 команда

LOOP/LOOPx   
Loop control   
(LOOPE, LOOPNE, LOOPNZ, LOOPZ) if (x && CX--) goto lbl;

Есть ли для неё аналог во всех других процессорах (ну или хотя бы самых распространённых, типа msp430, arm, MCS51 и тд?

Эмм.. А зачем такая чуча, если есть JEQ c CMP? Пойми, то что в msp430 этот loop будет заменен двумя инструкциями ни к чему плохому не приведет. Скорость будет та же (или выше), в плане предсказуемости тайминга тоже ничего не изменится.

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

Чего уж сразу в язык не ввести fft, dct и вейвлеты?

[Geniepro]

Чего уж сразу в язык не ввести fft, dct и вейвлеты?

Во, взял на заметку! ))))

[Valery Solovey]

Между прочим, мы отклонились от изначальной темы - ужель bytestream придется делать в виде пачки integer'ов или set'ов?

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

[Valery Solovey]

Чего уж сразу в язык не ввести fft, dct и вейвлеты?

Во, взял на заметку! ))))

О чём это вы?