Oberon space
General Category => Общий раздел => Тема начата: valexey_u от Декабрь 13, 2012, 02:12:49 pm
-
Вопрос - как сделать подобную абстракцию? То есть какие базовые типы для этого использовать.
В качестве элементарного строительного блока CHAR не подходит, потому, что он не байт по определению (CHAR в этом Обероне может быть например 32битным).
INTEGER - знаковый. И не очень понятно что с ним будет при сдвигах туда-сюда.
Остается разве что SET, который надо будет расчленять на четыре подмножества. Эффективность конечно будет...
-
BYTE же есть
-
Где?
-
Вопрос - как сделать подобную абстракцию?
Для начала нужно ответить на вопрос: "Нахрена?" ;)
-
BYTE же есть
Нет.
-
Вопрос - как сделать подобную абстракцию?
Для начала нужно ответить на вопрос: "Нахрена?" ;)
Ну, например имеем функцию которая читает из файла (например сокета), что у нее должно быть на выходе?
-
INTEGER
-
INTEGER
Ну то бишь 10 прочитанных байт - это 40 байт в памяти :)
-
INTEGER
Ну то бишь 10 прочитанных байт - это 40 байт в памяти :)
O_O
А в случае 64битной системы, 80 байт?
-
Ну да...
CHAR то ведь вроде равен по размеру INTEGER'у (или не? ???)
Т.е. литера в памяти всегда 4 байта даже если это ASCII
Хотя может я ошибаюсь.
-
BYTE же есть
Нет.
Напильник! ;)
P.S. В самой последней виртовской редакции - есть.
-
И вообще... Нашли к чему прикопаться. Вот в жабаскрипте байта тоже нет - и ниче, файлы читают...
-
P.S. В самой последней виртовской редакции - есть.
BOOLEAN the truth values TRUE and FALSE
CHAR the characters of a standard character set
INTEGER the integers
REAL real numbers
LONGREAL real numbers
SET the sets of integers between 0 and 31
http://www.inf.ethz.ch/personal/wirth/Articles/Oberon/Oberon07.Report.pdf
-
http://www.inf.ethz.ch/personal/wirth/Articles/Oberon/Oberon07.Report.pdf
Там еще за 2012 есть редакция.
-
Там еще за 2012 есть редакция.
O_o фигасе!
-
А где оно там? Чет я не бачу...
-
А где оно там? Чет я не бачу...
Да, странно, что ее там нет. Мне valexey давал ссылку.
-
Хм.. действительно:
http://forum.oberoncore.ru/viewtopic.php?f=115&t=615&hilit=Oberon07&start=200#p73582
I have made an addition to Oberon-7:
I added the basic type BYTE.
It is fully compatible with INTEGER, of which it denotes the subrange 0 ...
255.
Overflow may occur upon assignment of an integer to a variable of type BYTE.
I have removed the type LONGREAL.
Which standard is used is left open to every implementation.
Furthermore, there are again only 2 kinds of parameters,
the CONST case is dropped.
However, I introduce the restriction that assignments to elements of a structured parameter are forbidden, unless it is a VAR parameter.
(As a result, structured parameter can always be passed by reference).
I append the updated Report.
-
Ну и собсно оно во вложении
-
Хм.. действительно:
Overflow may occur upon assignment of an integer to a variable of type BYTE.
Гы! Сначала этого не заметил. Правильной дорогой идет товарищ - прямиком к C и прочим неявным приведениям типа ;)
-
Чегой то его не туда понесло...
-
Чегой то его не туда понесло...
Да, начиная, собственно, с первого О-7 Вирта действительно понесло. Идеологам с оборонкоре все труднее под него подложиться. WITH выпилил (сколько гордости было по поводу этой чисто обероновской суперфиче), динамические массивы выпилил, вложенные процедуры выпилил... зато добавил BYTE с неявным "небезопасным" приведением от INTEGER...
-
Астробовцы вон тоже байт воткнули:
http://www.astrobe.com/forum/viewtopic.php?f=4&t=214&sid=b38e4b81f49dae663919011332bc3738
-
BYTE же есть
Нет.
Напильник! ;)
P.S. В самой последней виртовской редакции - есть.
У меня ощущение что та редакция была чисто черновиком.
Но вообще, byte (который unsigned) в языке нужен - это ж элементарный строительный блок. Без него или System, или костыли с оверхедом диким.
-
А где оно там? Чет я не бачу...
http://oberspace.dyndns.org/index.php/topic,296.0.html
-
Чегой то его не туда понесло...
Да, начиная, собственно, с первого О-7 Вирта действительно понесло. Идеологам с оборонкоре все труднее под него подложиться. WITH выпилил (сколько гордости было по поводу этой чисто обероновской суперфиче), динамические массивы выпилил, вложенные процедуры выпилил... зато добавил BYTE с неявным "небезопасным" приведением от INTEGER...
Погодь, а когда и где он успел вложенные выпилить?
-
Погодь, а когда и где он успел вложенные выпилить?
Дык, обсуждали на оборонкоре. Хотя может и путаю (хотел выпилить, но пока оставил).
-
Вроде на месте они:
ProcedureDeclaration = ProcedureHeading ";" ProcedureBody ident.
ProcedureHeading = PROCEDURE identdef [FormalParameters].
ProcedureBody = DeclarationSequence [BEGIN StatementSequence]
[RETURN expression] END.
DeclarationSequence = [CONST {ConstDeclaration ";"}]
[TYPE {TypeDeclaration ";"}]
[VAR {VariableDeclaration ";"}]
{ProcedureDeclaration ";"}.
ps А семантически хрен знает...
-
В общем есть их там:
All constants, variables, types, and procedures declared within a procedure body are local to the procedure
-
А где оно там? Чет я не бачу...
http://oberspace.dyndns.org/index.php/topic,296.0.html
Я уж и забыть успел однако ::) :D
-
Но вообще, byte (который unsigned) в языке нужен - это ж элементарный строительный блок. Без него или System, или костыли с оверхедом диким.
В общем случае железо может не оперировать байтами. Правда, на ПК в силу повальной intelизации такого, наверно, не будет. А в других местах оно, возможно, отмирает. Чтобы всё было параллельно и перпендикулярно.
Но если исходить из предположения, что байт есть не на всех железках, то штука, манипулирующая именно байтами, доступна не везде, соответственно, работать тоже будет не везде. Поэтому загнать эти входящие и исходящие потоки в подсистему Host и при их реализации использовать System. И байт.
-
Но вообще, byte (который unsigned) в языке нужен - это ж элементарный строительный блок. Без него или System, или костыли с оверхедом диким.
В общем случае железо может не оперировать байтами. Правда, на ПК в силу повальной intelизации такого, наверно, не будет. А в других местах оно, возможно, отмирает. Чтобы всё было параллельно и перпендикулярно.
А при чем тут Интел? Наверное имелось ввиду x86? Но ведь и он тут не при чем. Возьмем arm, ppc, mips, alpha, итаник, да и тот же intel 8051, ti msp430, pic, atmel - ни один из них и близко не x86, но у всех них есть самый обычный байт.
Но если исходить из предположения, что байт есть не на всех железках, то штука, манипулирующая именно байтами, доступна не везде, соответственно, работать тоже будет не везде. Поэтому загнать эти входящие и исходящие потоки в подсистему Host и при их реализации использовать System. И байт.
Глупости. БАЙТ - есть везде. Только он не везде был 8 бит :-)
Алсо, чтобы не быть голословным, приведи плиз примеры современных (то есть производимых и используемых ныне) архитектур где нет байта, или хотя бы где байт не равен 8ми битам.
PS. И если уж так подходить к делу, то в SYSTEM первым делом должен улететь REAL и LONGREAL, а вторым делом туда же отправляется операция умножения и деления целых - вот они то точно не на всех современных архитектурах имеются.
-
Но вообще, byte (который unsigned) в языке нужен - это ж элементарный строительный блок. Без него или System, или костыли с оверхедом диким.
В общем случае железо может не оперировать байтами.
Так не бывает :) Никто не говорит, что байт должен быть 8-битным как на интеле. Байт - это минимальная адресуемая ячейка памяти на данной железке (собственно char в C как-то так и определен). И valexey прав, что без такой штуки действительно трудно эффективно работать с железкой (на что всегда претендовал оберон, в отличие от всяких жабаскриптов).
-
Так не просто бывает. Так есть. Процессор оперирует словами. На ПК популярным становится слово в 64 бита. Где-то слово равно байту. Если слово 64 бита, а процессор разрешает обратиться к байту (интел это для обратной совместимости делает), то работа с байтом будет максимум такой же производительной, как и со словом целиком (но поговаривают, что на самом деле работать будет чуть-чуть медленнее, чем со словом).
-
А при чем тут Интел? Наверное имелось ввиду x86?
Нет, я не про платформу говорил, а про политику компании.
-
Так не просто бывает. Так есть. Процессор оперирует словами. На ПК популярным становится слово в 64 бита. Где-то слово равно байту. Если слово 64 бита, а процессор разрешает обратиться к байту (интел это для обратной совместимости делает), то работа с байтом будет максимум такой же производительной, как и со словом целиком (но поговаривают, что на самом деле работать будет чуть-чуть медленнее, чем со словом).
Нет. Ты путаешь машинное слово, которое связывают с разрядностью шины данных и которое обычно отражают на сишный int, и минимально возможная адресуемая сущность в памяти (байт/char). А еще есть разрядность шины адреса, которая соответствует указательному типу ;)
-
примеры современных (то есть производимых и используемых ныне) архитектур где нет байта, или хотя бы где байт не равен 8ми битам.
Я же вначале сделал оговорку, из которой можно понять, что текущим положением дел не интересуюсь. Но в памяти всплывают какие-то обрывки про процессора, работающие с памятью исключительно с помощью слов в два байта (но внутри процессора их можно обрабатывать отдельно). Старьё? Возможно. Но в x64 до сих пор есть вещи, ктоторые появились в первых моделях процессора. Тоже старьё. Но существует пока. Почему бы не существовать и другому какому-нибудь архаизму в виде такого странного процессора? Потенциально.
-
Так не просто бывает. Так есть. Процессор оперирует словами. На ПК популярным становится слово в 64 бита. Где-то слово равно байту. Если слово 64 бита, а процессор разрешает обратиться к байту (интел это для обратной совместимости делает), то работа с байтом будет максимум такой же производительной, как и со словом целиком (но поговаривают, что на самом деле работать будет чуть-чуть медленнее, чем со словом).
Это конечно здорово, однако ж что делать с файлом размер которого 5 байт? ;-) Чем его читать?
Вообще, байт это вот такая штука:
The byte (play /ˈbaɪt/) is a unit of digital information in computing and telecommunications that most commonly consists of eight bits. Historically, a byte was the number of bits used to encode a single character of text in a computer[1][2] and for this reason it is the basic addressable element in many computer architectures. The size of the byte has historically been hardware dependent and no definitive standards existed that mandated the size. The de facto standard of eight bits is a convenient power of two permitting the values 0 through 255 for one byte. With ISO/IEC 80000-13, this common meaning was codified in a formal standard.
И без него весьма хреново на самом деле. И уж иметь в языке только знаковые целые (которые годятся только для арифметики) и SET, который прибит гвоздями к 32битам, вообще как-то даже стыдно.
Если уж на то пошло, то и байт это не всегда удобно. Иногда нужно не bytestream а bitstream. То есть, говоря высокоуровнево, в языке нужен инструмент для удобного и эффективного разбора бинарных данных произвольной длины. В Обероне такового инструмента видимо нет (на эту роль претендует SET, но он, очевидно, совершенно не годится) и сконструировать не получается. А вот скажем в erlang'e он есть (не факт что очень эффективный, но по крайней мере до жути удобный). В сях есть bitfield'ы и все ж таки есть честный байт (начиная с C99).
-
Нет. Ты путаешь машинное слово, которое связывают с разрядностью шины данных и которое обычно отражают на сишный int, и минимально возможная адресуемая сущность в памяти (байт/char).
Грубо говоря, если штука по адресу 1234 никак не пересекается со штукой по адресу 1235, то это штука - машинный байт.
-
примеры современных (то есть производимых и используемых ныне) архитектур где нет байта, или хотя бы где байт не равен 8ми битам.
Я же вначале сделал оговорку, из которой можно понять, что текущим положением дел не интересуюсь. Но в памяти всплывают какие-то обрывки про процессора, работающие с памятью исключительно с помощью слов в два байта (но внутри процессора их можно обрабатывать отдельно). Старьё? Возможно. Но в x64 до сих пор есть вещи, ктоторые появились в первых моделях процессора. Тоже старьё. Но существует пока. Почему бы не существовать и другому какому-нибудь архаизму в виде такого странного процессора? Потенциально.
А я не интересуюсь десктопными x86/amd64 процессорами. Серьезно. Я интересуюсь (и for fun, и по работе) msp430 и прочей подобной радостью (если что msp430 распространен больше чем всякие там x86). Так вот - там нет и не будет чисел с плавающей точкой, и там нет и не будет умножения и деления целых чисел. Всвязи с этим предлагаю REAL, LONGREAL а также операцию умножения и деления переместить в SYSTEM! Програмно эмулировать скажем умножение чисел с плавающей точкой - жутко не эффективно (как по памяти, так и по времени, по времени оно еще и не предсказуемо, пока-пока реалтайм!). А SET либо сделать 16ти битным, либо тоже в SYSTEM утащить (32битных целых там тоже нет). И вот ТОГДА Оберон точно станет действительно кроссплатформенным языком!
И я не издеваюсь. Это реальная проблема. И актуальная архитектура. И она такова by design и это оправдано, это не архаизмы.
-
PS. И если уж так подходить к делу, то в SYSTEM первым делом должен улететь REAL и LONGREAL, а вторым делом туда же отправляется операция умножения и деления целых - вот они то точно не на всех современных архитектурах имеются.
Насчёт реала - не имею мнения, а умножение и деление - это не команды процессора, а абстракции. Их место - в языке, их машинное представление - дело оптимизатора кода.
-
Нет. Ты путаешь машинное слово, которое связывают с разрядностью шины данных и которое обычно отражают на сишный int, и минимально возможная адресуемая сущность в памяти (байт/char).
Пока что эта фраза меня не убедила. С трудом себе представляю, что по 64-шине передано всего 8 бит.
-
Нет. Ты путаешь машинное слово, которое связывают с разрядностью шины данных и которое обычно отражают на сишный int, и минимально возможная адресуемая сущность в памяти (байт/char).
Пока что эта фраза меня не убедила. С трудом себе представляю, что по 64-шине передано всего 8 бит.
Я один вещь скажу, не обижайся пожалуйста :-) Но по шине памяти передается не 64 бита. а сразу целиком cache line, То есть 64 БАЙТА. Это на современных x86. Но это не отменяет побайтной адресации ;-) Там сейчас очень хитрая многослойная интеллектуальная система. Без поллитры не разобраться.
-
PS. И если уж так подходить к делу, то в SYSTEM первым делом должен улететь REAL и LONGREAL, а вторым делом туда же отправляется операция умножения и деления целых - вот они то точно не на всех современных архитектурах имеются.
Насчёт реала - не имею мнения, а умножение и деление - это не команды процессора, а абстракции.
В смысле абстракции? Самые что ни на есть реальные команды. Отсутствие этих команд в процессоре приводит к много бОльшим проблемам в случае их использования в программе, чем использования 8битного байта при 16ти битной адресации памяти (то есть когда минимальная адресуемая ячейка 16 бит).
Их место - в языке, их машинное представление - дело оптимизатора кода.
Точно также можно сказать, что представление байта - дело оптимизатора кода.
-
А SET либо сделать 16ти битным, либо тоже в SYSTEM утащить (32битных целых там тоже нет). И вот ТОГДА Оберон точно станет действительно кроссплатформенным языком!
Насчёт SETа тоже мнения не имею, поскольку не пользовался особо. А вот насчёт кроссплатформенного языка высказаться могу.
Я не считаю, что кроссплатформенным называется язык, содержащий в себе только те команды, которые есть на всех охватываемых платформах. А считаю, что это язык, исходный код на котором можно скомпилировать под платформы, запустить результат на платформах и получить везде одинаковый результат.
И я не издеваюсь. Это реальная проблема. И актуальная архитектура. И она такова by design и это оправдано, это не архаизмы.
А я и не считал это издевательством. И архаизмом назвал не байт, а нестандартные процессора.
Хотя нет, байт тоже архаизм : ). Кому он нужен? Всем нужны потоки, из которых достаются данные. Сейчас-то они представлены в виде байтов, но лучше бы уж представлялись сразу в виде данных.
-
В смысле абстракции? Самые что ни на есть реальные команды. Отсутствие этих команд в процессоре приводит к много бОльшим проблемам в случае их использования в программе, чем использования 8битного байта при 16ти битной адресации памяти (то есть когда минимальная адресуемая ячейка 16 бит).
В смысле, абстракции языка программирования. Как они лягут на железо решает разработчик компилятора.
Их место - в языке, их машинное представление - дело оптимизатора кода.
Точно также можно сказать, что представление байта - дело оптимизатора кода.
Что-то я не понял... Оптимизатор кода сделает в процессоре байт того размера, который прописан в исходнике? : )
-
Я не считаю, что кроссплатформенным называется язык, содержащий в себе только те команды, которые есть на всех охватываемых платформах. А считаю, что это язык, исходный код на котором можно скомпилировать под платформы, запустить результат на платформах и получить везде одинаковый результат.
Ну так вот, с умножением в языке ты не получишь одинаковый результат - на одной платформе у тебя тайминг будет четкий и ровный, на другой будет скакать как шимпанзо и очевидно зависить от значений операндов.
И я не издеваюсь. Это реальная проблема. И актуальная архитектура. И она такова by design и это оправдано, это не архаизмы.
А я и не считал это издевательством. И архаизмом назвал не байт, а нестандартные процессора.
Хотя нет, байт тоже архаизм : ). Кому он нужен? Всем нужны потоки, из которых достаются данные. Сейчас-то они представлены в виде байтов, но лучше бы уж представлялись сразу в виде данных.
Ну, таки потоки данных нужны битовые все же. Байт в этом плане действительно архаизм. Поток данных в виде сразу данных предметной области - не выйдет. Не нужно пытаться выкинуть нижний уровень представления данных, это никогда ни к чему хорошему не приводит.
PS. У процессоров ARM есть множество преимуществ перез x86/amd64 - они меньше, энергоэффективней и так далее. Но у них есть один фейл - они с сетью работают довольно медленно. Почему? А потому, что им таки нужно выравнивать данные. Они могут работать с не выровненными, но ме-едленно, в отличае от x86. В результате tcp/ip стек и другие сетевые протоколы процессор разбирает существенно медленней (на самом деле это моя догадка - нужно перепроверить). Так что байт рулит. Но байт в этой задаче - костыль. А нужно бы решить непосредственную задачу - удобный и быстрый разбор бинарных данных/протоколов.
-
В смысле абстракции? Самые что ни на есть реальные команды. Отсутствие этих команд в процессоре приводит к много бОльшим проблемам в случае их использования в программе, чем использования 8битного байта при 16ти битной адресации памяти (то есть когда минимальная адресуемая ячейка 16 бит).
В смысле, абстракции языка программирования. Как они лягут на железо решает разработчик компилятора.
Точно также как и типы данных.
Их место - в языке, их машинное представление - дело оптимизатора кода.
Точно также можно сказать, что представление байта - дело оптимизатора кода.
Что-то я не понял... Оптимизатор кода сделает в процессоре байт того размера, который прописан в исходнике? : )
Естественно. Сказано в спеке на язык, что тип BYTE это ВСЕГДА 10 бит - так оно и будет. Но при чем тут процессор? Процессор штука забавная, и понятием байт вообще не оперирует :-) Там все интересней.
-
...
Так вот - там нет и не будет чисел с плавающей точкой, и там нет и не будет умножения и деления целых чисел. Всвязи с этим предлагаю REAL, LONGREAL а также операцию умножения и деления переместить в SYSTEM! Програмно эмулировать скажем умножение чисел с плавающей точкой - жутко не эффективно (как по памяти, так и по времени, по времени оно еще и не предсказуемо, пока-пока реалтайм!).
...
И я не издеваюсь. Это реальная проблема. И актуальная архитектура. И она такова by design и это оправдано, это не архаизмы.
В этом нет никакого смысла. В таких (да и многих других) процессорах нет тех же циклов, да даже оператора IF нет -- но это же не означает, что эти конструкции языка высокого уровня надо выкинуть только потому, что они эмулируются кучей дополнительных машинных команд. ЯВУ потому и ЯВУ что 1 команда программы на ЯВУ компилируется в десятки, сотни или даже тысячи команд машинного кода.
Так что в нормальном ЯВУ (а не в ассемблере) должны быть языковые плавающая арифметика и умножение/деление целых чисел. Да даже комплексные числа -- почему бы и нет? В последних стандартах С они уже тоже есть!
-
Да даже комплексные числа -- почему бы и нет? В последних стандартах С они уже тоже есть!
Студенты, видимо, пролоббировали... :) Потому как лабы являются главным "потребителем" необходимости комплексных чисел в ЯП общего назначения.
-
Ну так вот, с умножением в языке ты не получишь одинаковый результат - на одной платформе у тебя тайминг будет четкий и ровный, на другой будет скакать как шимпанзо и очевидно зависить от значений операндов.
Гарантии реалтайма к языку уже не относятся.
И даже если такая проблема возникнет -- ну так пусть программист и не пользуется тем, что есть не на всех ему нужных процессорах -- умножением, делением, циклами, ветвлениями, записями, и прочим-прочим-прочим. Это уже его личная проблема.
-
Да даже комплексные числа -- почему бы и нет? В последних стандартах С они уже тоже есть!
Студенты, видимо, пролоббировали... :) Потому как лабы являются главным "потребителем" необходимости комплексных чисел в ЯП общего назначения.
Если я не ошибаюсь, комплексные числа нужны во всяких там преобразованиях Фурье, так что, видимо, в промышленности тоже востребованы...
-
...
Так вот - там нет и не будет чисел с плавающей точкой, и там нет и не будет умножения и деления целых чисел. Всвязи с этим предлагаю REAL, LONGREAL а также операцию умножения и деления переместить в SYSTEM! Програмно эмулировать скажем умножение чисел с плавающей точкой - жутко не эффективно (как по памяти, так и по времени, по времени оно еще и не предсказуемо, пока-пока реалтайм!).
...
И я не издеваюсь. Это реальная проблема. И актуальная архитектура. И она такова by design и это оправдано, это не архаизмы.
В этом нет никакого смысла. В таких (да и многих других) процессорах нет тех же циклов, да даже оператора IF нет -- но это же не означает, что эти конструкции языка высокого уровня надо выкинуть только потому, что они эмулируются кучей дополнительных машинных команд.
В плане IF'ов и циклов там все то же самое что в x86. Принципиальных отличий нет. Так что это мимо кассы.
Так что в нормальном ЯВУ (а не в ассемблере) должны быть языковые плавающая арифметика и умножение/деление целых чисел. Да даже комплексные числа -- почему бы и нет? В последних стандартах С они уже тоже есть!
В нормальном ЯВУ это все делается либой и тащить в язык это не требуется :-) А вот Си действительно нормальным языком не является, поэтому там пришлось вшить комплексные числа в язык. :-)
-
Между прочим, мы отклонились от изначальной темы - ужель bytestream придется делать в виде пачки integer'ов или set'ов?
-
В плане IF'ов и циклов там все то же самое что в x86. Принципиальных отличий нет. Так что это мимо кассы.
Разве? Вот есть, например, в x86 команда
LOOP/LOOPx
Loop control
(LOOPE, LOOPNE, LOOPNZ, LOOPZ) if (x && CX--) goto lbl;
Есть ли для неё аналог во всех других процессорах (ну или хотя бы самых распространённых, типа msp430, arm, MCS51 и тд?
-
Между прочим, мы отклонились от изначальной темы - ужель bytestream придется делать в виде пачки integer'ов или set'ов?
А bytestream вообще идиоматичен для оберонщиков? Может и не надо его делать в Обероне?
-
В плане 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 и вейвлеты?
-
Чего уж сразу в язык не ввести fft, dct и вейвлеты?
Во, взял на заметку! ))))
-
Между прочим, мы отклонились от изначальной темы - ужель bytestream придется делать в виде пачки integer'ов или set'ов?
Я не отклонялся от темы. Я предлагал сделать тип данных Поток, который внутри реализуется через байт (и system), а наружу выставляет процедуры чтения интов, строк и т.д.
-
Чего уж сразу в язык не ввести fft, dct и вейвлеты?
Во, взял на заметку! ))))
О чём это вы?
-
Между прочим, мы отклонились от изначальной темы - ужель bytestream придется делать в виде пачки integer'ов или set'ов?
Я не отклонялся от темы. Я предлагал сделать тип данных Поток, который внутри реализуется через байт (и system), а наружу выставляет процедуры чтения интов, строк и т.д.
Это слишком тяжеловесно не гибко и компиляторозависимо.
По факту - в реализациях в SYSTEM'e нет байта. Кстати, псевдомодуля SYSTEM также может не быть - он опционален.
-
Чего уж сразу в язык не ввести fft, dct и вейвлеты?
Во, взял на заметку! ))))
О чём это вы?
Ну как о чём? Надумаю делать свой ЯВУ -- забубеню туда "fft, dct и вейвлеты" (что бы это не значило) ;D
-
Так что в нормальном ЯВУ (а не в ассемблере) должны быть языковые плавающая арифметика и умножение/деление целых чисел. Да даже комплексные числа -- почему бы и нет?
Категорически... СОГЛАСЕН! :)
-
Между прочим, мы отклонились от изначальной темы - ужель bytestream придется делать в виде пачки integer'ов или set'ов?
Я не отклонялся от темы. Я предлагал сделать тип данных Поток, который внутри реализуется через байт (и system), а наружу выставляет процедуры чтения интов, строк и т.д.
Вполне кошерно по Вирту :D
-
Я не отклонялся от темы. Я предлагал сделать тип данных Поток, который внутри реализуется через байт (и system), а наружу выставляет процедуры чтения интов, строк и т.д.
Вполне кошерно по Вирту :D
Не, даже с таким потоком все равно будет специфика платформы. Например, как будут читаться int'ы - как big-endian или little-endian? А размеры этих int'ов?
-
Я не отклонялся от темы. Я предлагал сделать тип данных Поток, который внутри реализуется через байт (и system), а наружу выставляет процедуры чтения интов, строк и т.д.
Вполне кошерно по Вирту :D
Не, даже с таким потоком все равно будет специфика платформы. Например, как будут читаться int'ы - как big-endian или little-endian? А размеры этих int'ов?
Или как middle-endian :-) (да, есть и такое)
-
Не понял при чем тут это.
Читаем поток 10 байт - получаем 10 int'ов... Как конкретно байт ляжет на int зависит от компилятора. SYSTEM - это ведь псевдомодуль (т.е. по сути часть компилятора)
Ну а компилятор то платформу должен "знать".
-
Не понял при чем тут это.
Читаем поток 10 байт - получаем 10 int'ов... Как конкретно байт ляжет на int зависит от компилятора. SYSTEM - это ведь псевдомодуль (т.е. по сути часть компилятора)
Ну а компилятор то платформу должен "знать".
Он должен знать формат исходного потока. Потому что если на одной платформе один компилятор положит (в файл) big-endian, а другой прочитает в little-endian, то исходный и прочитанный int'ы не совпадут. При этом даже если заспекать такой формат - часть платформ окажется в проигрыше по эффективности работы с таки потоком, потому что будет постянно перегонять в правильный endian.
-
Хоть убейте, но я все равно не понимаю какое отношение это имеет к Оберону. На любом другом языке будет ровно то же самое.
-
Хоть убейте, но я все равно не понимаю какое отношение это имеет к Оберону. На любом другом языке будет ровно то же самое.
Никакого. Общие размышления. Поток будет всяко лучше, чем отсутствие даже BYTE :)
-
В общем, у меня таки оформилось мнение, что подобную штуку следует делать через opaque-тип в стандартной либе. Непосредственно модуль реализующий этот opaque-тип может использовать (внутри себя) внеязыковые средства для пущей эффективности.