SfS, так спектрум изначально и создавался как обучающий "домашний" ПеКа. Разве, нет?
А игровой платформой, он стал скорее, вопреки.
- - - Добавлено - - -
Диалекты ЯВУ для спектрума, как и компиляторы - огромных размеров костыль. Да, расширяют функционал. Да, дают прирост в скорости выполнения программы. Но, как правило, все это ценой, сжирания почти всей доступной памяти.
Когда есть, но не знаешь где - это все равно, что нету.
Он создавался как "бытовой ПК" с низкой стоимостью. Для того времени - вполне нормальный.Сообщение от null_device
Но это никакого отношения к архитектуре ПО не имеет. Просто, как я понимаю, ПО писалось в сжатые сроки по принципу "херак-херак и в продакшн".
Изначальной проработки архитектуры ПО, позволяющей подключать например новые устройства - вообще не было. Хотя новые устройства расширения предполагались изначально.
А как бы помогла возможность без извращений, например, добавлять новые команды в бейсик. Появилось новое устройство - бамс, добавило свою команду со своим обработчиком. Всё. Не надо перехватывать адреса обработчика ошибок и писать костыль.
Или стандартизированное API для вызова подпрограмм ПЗУ - как его не хватало.
Но вместо этого приходилось наворачивать костыли типа "а вот по такому адресу есть такая подпрограмма, надо сбросить эти флаги, выставить вот эти, в регистры DE надо записать нуль, а в DE' надо записать FF, иначе оно не работает" и после этих манипуляций вызывайте.
Следствие этого - ошибки не исправлялись никогда практически (например, в "калькуляторе" их немало). Ибо Клайв очканул, что будет "несовместимость".
Другое следствие - миллион велосипедов, чтобы обойти ограничения бейсика. Наверное каждый писал свой ПРИНТ и свой ИНПУТ.
А ведь такое гениальное решение, как аналог sprintf() в языке C позволило бы избавиться от кучи разных "принтов". Точнее, упростить их до уровня "вывод символа".
В некоторых местах - вообще ни логики ни смысла. Например, если мы рисуем круг или линию, часть которой выходит за экран - то "Out of Range". А ПОЧЕМУ?!
Что мешает нарисовать часть линии, которая видна? Безо всяких ошибок? В чём именно ОШИБКА, если часть круга вылазит за экран?
Об ошибках бейсика. Нет вообще средств их перехвата и обработки. Скажем, бабах и деление на нуль. И всё. Никак не обработать средствами только бейсика.
В калькуляторе вообще не должно быть "ошибок" при операции над числами по идее. Если число сильно велико по модулю - то просто должно возвращаться значение "бесконечность". Если пытаются сложить число и строку - то правила наподобие тех, как в javascript. Но не генерить на каждый чих "Error".
Да и код попроще был бы.
Недаром, всё это вошло потом в мега- бета- бейсики. Ибо очень надо было многим.
В общем, с высоты теперешнего опыта (более четверти века микроконтроллеров и линукс-систем) я понимаю, как примитивно и неказисто выглядит бейсик спектурма. И дело не в том, что "памяти мало, а проц на 3.5мгц", а в том, что делалось быстро и лишь бы сделать. Увы, это так.
Oleg N. Cher (15.11.2023)
Есть примеры "правильных" реализаций ПО бытовых компьтеров?
"Во времена всеобщей лжи говорить правду - это экстремизм" - афоризм.
Barmaley_m (15.11.2023)
Где-то неэффекттивен, но улучшения предлагать надо с осторожностью. Вот я как-то думал, с высоты опыта, что могу улучшить кассетный формат без потери его устойчивости к искажениям сигнала. Казалось, что вся теория была "за". Однако практика показала, что формат FM по каким-то неведомым мне пока причинам обладает исключительной стойкостью к искажениям, достичь которой другим способом не удалось. И действительно, сегодня подобное кодирование применяется в радио-стандарте LoRa, где важна не скорость, а дальность передачи.
И таких примеров много.
Быстрой - до момента достижения критической фрагментации памяти.
Текущую реализацию можно улучшить. Но с кучами на 8-битных архитектурах надо осторожнее. На них в свое время применялись другие, хорошо забытые, трюки - например, Gap Buffer. По сути тот же стек, но 2шт. Можно сделать и больше стеков, динамически их уплотнять и разуплотнять и т.д. В общем, не кучей единой, особенно, когда памяти мало. А еще все эти красивые вещи надо разработать на ассемблере и уместить в 16К ПЗУ.
Тут да, вероятнее всего, сказывается отсутствие интернета, соответствующей литературы, или банально времени у авторов.
Да. И при всем при этом они создали вполне неплохой бейсик. Они смогли. А мы не смогли, хотя и литературы валом, и знаний, и опыта. Мне приходит иногда идея: "А не запилить ли бейсик на современных технологиях для Спектрума?" Но дальше идеи дело не идет. А ты бы хотел запилить хороший, правильный бейсик?
- - - Добавлено - - -
Кое-какая проработка была, например, нереализованные команды MOVE, ERASE, CAT, FORMAT, и едва реализованная OPEN#. Тут причина только в том, что времени не хватило. Где-то пробегало даже интервью, где Синклер или разработчики его бейсика прямо говорили, почему не закончили подсистему ввода-вывода. Как есть - так есть.
Перехват обработчика - не такой уж и костыль. Если имеешь книгу Логана и О-Хары - то написать обработчик, добавляющий в бейсик новые команды, не так уж и сложно. С API было бы не проще, разве что только "стандартнее". Я как-то развлекался добавлением в бейсик новых команд, внося изменения в ПЗУ. Удалось органично встроиться в соответствующие процедуры, но каких-то больших преимуществ, по сравнению с написанием обрабочика, этот способ не имеет.
Более того, расширяемость некоторых библиотек на том и построена, что следует добавить в обработчик неизвестных библиотеке ситуаций свою часть для добавления функционала. Далеко ходить не надо - оконная система Windows использует этот способ.
Не знаю, кому не хватало. Неизменность ПЗУ за все время жизни компьютера - чем не стандартизированное API? Вызывай когда хочешь и что хочешь, а не нравится - не вызывай, пиши своё. С другой стороны, любое API всегда ломается при переходе на новую версию - даже в тех проектах (напр. Windows), где обратная совместимость возведена в ранг высших ценностей.
А в чем проблема выставить регистры? Параметры надо как-то передавать, и регистры - самый быстрый способ это сделать. Большинство подпрограмм ПЗУ (LOAD, SAVE, BEEP, PLOT, DRAW, калькулятор и мн. др.) были вполне себе изолированы и не требовали предстартовой подготовки.
Не факт, что именно из-за этого. В Spectrum +2 и Spectrum-128 в прошивку было внесено немало изменений, и никто не очканул. Возможно, дело было просто в деньгах. Зачем вкладывать деньги в исправление ошибок, если эти ошибки незначительны по своим последствиям и не влияют на популярность продукта и его продажи?
А универсальный принт, одинаково полезный для всех, не сделаешь. Одному покажется, что в принте мало функций; другому покажется, что он медленно работает; третьему хочется перетереть системные переменные, а без них принт не работает. Писали своё либо тогда, когда имеющееся не подходило, либо просто для развития.
Не позволило бы. Даже sprintf подходит не всегда и не всем, особенно, если нужно выжать последние крохи по быстродействию.
А потому, что идеология бейсика (не только на Спектруме) всегда была в том, чтобы останавливать программу при малейшей ошибке, а не продолжать ее выполнение, как к тому привыкли Сишники.
Кому-то это неудобно, зато обеспечивается полная проверка корректности программы во время исполнения. Я бы с удовольствием имел интерпретатор Си, который валится при любом Undefined Behavior. Для отладки и тестов бы использовал. Но такового нету.
Помню, что мои бейсик-программы тех времен были достаточно надежные, чтобы не вылетать по ошибкам. Неудобства доставляло только нажатие пользователем клавиши Break и ошибки ввода-вывода. Но для их перехвата были специальные средства. Кто хотел - тот имел.
Ошибка в том, что поступившая от пользователя команда - нарисовать нечто за пределами экрана - не может быть исполнена. Классический отказ. Падать в случае его возникновения допустимо. Особенно учитывая роль бейсика как обучающего языка. В мои времена все бейсики вели себя так.
Стандартных средств нет, но наколхозить свои было чрезвычайно легко, учитывая легкость перехвата RST 8. В журналах и других источниках была куча маленьких подпрограмм в кодах "ON ERROR GOTO", позволявшие обрабатывать ошибки. Но поверь, не нужно это было так уж сильно. Если программа написана надежно - в ней не будет возникать ошибок, она не будет падать. Не надо делить на нуль - и все будет в порядке. А написание обработчиков ошибок - что для новичков, что для профессионалов - трудная задача. Слишком многое надо предусматривать. И отлаживать программу с обработчиком ошибок тяжело. Вот зациклился твой обработчик - что делать? Жать ресет, а потом грузить все заново с кассеты? Такое себе удовольствие.
Я никогда не применял на спектрум-бейсике обработчики ошибок, хотя знал об их существовании и написал на бейсике пару простых игр и других нетривиальных проектов.
Скажу тебе как программист, использующий и реализующий различные численные методы в повседневной работе.
Не надо это. Я не встречал в серьезной литературе ни одного описания или реализации численного алгоритма, который бы полагался при нормальной работе всякие Inf и NaN.
Не всякая бесконечность равна другой. Это только на первый взгяд заманчиво вычесть из Inf 1000 и убедиться, что остается Inf. А если умножить ее на нуль? А если прибавить -Inf? Не все аспекты математической бесконечности удается реализовать с помощью значения "Inf". Поэтому на него и не полагаются.
Если при работе численного алгоритма возникают Inf, NaN, или просто очень большие числа - то это не означает ничего хорошего. Либо в реализации ошибка, либо недопустимые исходные данные. В таком случае, чем раньше ошибка будет обнаружена, а программа - остановлена, тем легче ее наладить. А не разбираться потом, на каком этапе вычислений произошло переполнение, и почему массив выходных данных заполнен NaN.
А отлаживать численные методы - поверь, трудная задача. Этому нельзя научиться по книжкам, обучающим просто программированию. Мне пришлось на опыте выработать ряд специальных приемов для такой отладки. Может быть, кто-то уже написал соответствующую книжку, но я таковых пока не встречал.
Как раз с неделю назад смотрел видео с критикой различных языков программирования, там отдельный раздел был посвящен "интуитивным" правилам сложения различных несовместимых типов в Javascript. Как то некоммутативность такого сложения и неочевидность, почему получился тот или иной результат. На мой взгяд, такие вещи не способствуют обучению начинающих.
Или казалось, что надо. Я как-то не встречал больших и красивых проектов на этих бейсиках. Правда, не искал специально.
Большие и красивые проекты создавались на ассемблере. А там нет проблем с остановом программ по ошибке. Есть только проблемы с перепахиванием памяти и наступлении сбоев, которые потом трудно отследить. Благо только, что не было Undefined Behavior, а то бы многие программисты были доведены до белой горячки.
Так, да не так. Во-первых, я привел выше возражения. Во-вторых, этот бейсик вполне неплохо работал. А в-третьих - что мешает сделать свой, хороший бейсик, с блекджеком и шл.?
vlad-kras (16.11.2023)
А бог его знает. Наверное есть где-то что-то лучше.
Я ж просто теоретезирую))
Высказываю то, что не нравится. И не более.
Идея такая приходила. Но нужен он разве кому-то? Чисто поиграться разве что.
А так.. Все программы - ориентированы на стандартный васик спектрума.
Прошивать в ПЗУ другой васик тоже мало кто будет. В эмуле если только погонять. Ну и на тех машинах, где можно вместо ПЗУ воткнуть ОЗУ и заблокировать его.
- - - Добавлено - - -
Так "неизменность ПЗУ" и стала таковой именно изза того, что не было API. И ошибки неисправимы - ПЗУ ведь менять нельзя.
Банальный пул системных вызовов решил бы эту проблему. Ну да что есть то есть.
Вот странно, что в UNIX основные API не меняются десятилетиями)) Что они делают не так?)
Правда, внутри ядра Линукс очень часто API меняется. Но со стороны пользовательского ПО - как гвоздями прибито. Большая часть ПО 25 лет назад написанного спокойно компилится и работает.
- - - Добавлено - - -
Допустимо, но очень резко ограничивает возможности васика. И в чём обучение? В том, что нельзя две трети круга нарисовать, если треть на экране не поместилась? За то в DRAW передать всякую чушь и получить на экране красивый узор - это прям необходимость первая))
Мы говорим про ВАСИК и пользователя, пишушего на нём, без машкода. "Наколхозить" можно всё, что угодно. Но то, кто "обучается на васике" явно врядли способен "наколхозить" нужное и быстро.
- - - Добавлено - - -
Речь идёт о том, чтобы пользователь мог обработать ошибку. Получилось у него бесконечность - так он может, например, вывести сообщение, что заданы неверные параметры и предложить их поменять, а не валиться из программы.
Про "вычесть из бесконечности число" речь не идёт. NaN как таковой вообще не нужен в этом случае.
Впрочем, это то же самое, что и ONERROR. Но и ONERROR отсутствует.
- - - Добавлено - - -
Если смотреть с точки зрения обучения - то я соглашусь. Явные функции преобразования удобнее. Но это у же скорее всё "частности".
- - - Добавлено - - -
Ну так и на стандартном васике их какбы особо нет. Всё с асм-вставками.
Я не предлагал "а давайте запилим". Смысла не вижу сегодня это делать. Я просто описал, что лично мне не нравится в ZX васике.
такое давно существует https://zxdesign.itch.io/opense
andrews (20.11.2023), Barmaley_m (17.11.2023), Oleg N. Cher (18.11.2023)
Посмотрел. Долго его писали. И забили все 16К под завязку! Молодцы.
Завидую)
А мне, повторяю, кажется, что дело в деньгах. Зачем тратить деньги на зарплату программистов и пилить новое ПЗУ, если старое работает, и все довольны? Лучшее - враг хорошего.
Сколько-нибудь существенного улучшения бейсика добиться было невозможно. Бейсик-128 тому хороший пример. Когда захотели - то запилили еще 16К кода в ПЗУ. И часть старого поменяли, наплевав на несовместимость. А что улучшилось от этого? Если приходилось программировать на бейсике, имея 128й - то я предпочитал набрать usr0 и работать со старым бейсиком. Он был и удобнее, и надежнее, и новые функции 128го бейсика того не стоили.
А что ошибки "неисправимы" - то их там было кот наплакал. Не было из-за них критичного нарушения функционала. Находили их по большей части энтузиасты, вроде Яна Логана и О-Хары. Простому человеку на них наткнуться было очень маловероятно. В современных продуктах ошибки такого уровня могут быть известны, но никогда не исправляться. Даже если идет постоянная разработка новых версий, и обратная совместимость не важна. Потому, что есть более приоритетные задачи. Например, более серьезные ошибки или добавление функционала.
Я думаю, не решил бы. Всегда нашелся бы какой-нибудь умник, вызывающий напрямую какие-то процедуры, не вошедшие в "пул системных вызовов". Ну или пул менялся бы от версии к версии. Подобные меры способствуют совместимости новых версий библиотек со старыми, но не решают эту проблему полностью.
А толку от этого? Можно ли взять бинарник со старого Linux с совместимой архитектурой процессора, и запустить его на новой версии ОС? У Линукса проблемы совместимости старого софта с новыми версиями ОС огромные. Как там у коммерческих UNIX - не знаю, может, ты в курсе?
А под линуксом - бинарники не запускаются, а собирать проекты заново из исходников - длительное, требующее высокой квалификации и опыта, и рискованное дело. Не всегда удаётся. То одна ошибка компиляции, то другая. То одна библиотека не подходит, то другая. То в компиляторе что-то поменялось.
"Очень резко" - это как? Бейсик что, перестает от этого быть полным по Тьюрингу? Если программа написана без ошибок - то она не вызовет отказ и останов. В этом и цель программирования. Написать программу, которая решает некоторую задачу и при этом не сбивается.
В том, чтобы научить составлять надежные программы. В которых нет ошибок, которые кому-то хотелось бы "замести под ковёр". Чтобы программа была точно выверенной и в любых ситуациях не выходила за пределы заданных рамок.
Я понимаю, тебе очень не хватало клиппинга графики. Сочувствую.
А мне вот приходилось работать с другими бейсиками, где команды CIRCLE вообще не было. И знаний не хватало сделать свою реализацию на том же бейсике. Ну или тормозно это было. И ничего. Все равно программирование доставляло массу удовольствия и развития. Можно было реализовать массу других проектов. И без кругов (тем более - обрезанных) рисовалась прекрасная графика на экране.
Использовал даже бейсики, где вообще графики не было. РК-86 и "Агат". На последнем была некоторая графика... CIRCLE не было, но не это было основной проблемой. Основной было то, что в графическом режиме не было вывода текста! Нарисуешь, к примеру, график функции - а чем подписать оси?
Мы говорим про перехват ошибок. Начинающие обычно таким не заморачиваются - им бы хоть как-то держать равновесие в написании простейших программ. Не нужен им перехват ошибок.
Когда же обучающийся достигает такого уровня, что ему хочется и можется написать обработчик ошибок - тогда же он становится способен найти "колхозные" решения этой задачи в виде распространяемых через журналы или друзей маленьких подпрограмм в машинных кодах.
Перехват ошибок штатно имеется в некоторых бейсиках, например, бейсик-Агат (ONERR GOTO). Я стал играться с этим далеко не на первом году своего знакомства с бейсиком. И к тому времени я уже был в состоянии находить и использовать полезные подпрограммы в маш. кодах.
Не понимаю, зачем тебе все время хочется заниматься обработкой ошибок? Это же трудно и громоздко, и не способствует достижению основных целей программы, которую ты взялся писать.
Меня тема обработки ошибок интересует только как раздражитель. Как необходимое зло, которым приходится заниматься. Но, если можно этого избежать - то предпочитаю избежать. Особенно, если пишу программу-прототип для внутреннего применения - тогда лучше, чтобы она исполнялась на таком же чувствительном интерпретаторе, как бейсик, чтобы при первых признаках неполадок останавливалась. Тогда ее легче отлаживать.
Это же лишние трудозатраты. Проверить результат на выход за пределы допустимого диапазона. Вывести сообщение, предложить что-то поменять. Когда ты начинаешь писать и отлаживать какой-нибудь вычислительный алгоритм - то такая деятельность только отвлекает и повышает затраты времени и сил. Их лучше тратить на сам алгоритм. А обработкой ошибок пусть лучше занимается интерпретатор. Его задача - обнаружить сбой на возможно ранней стадии. И остановить программу, облегчая тем самым ее отладку.
А проверять лучше не результаты - они не всегда будут явно ошибочными. Лучше проверять исходные данные на допустимый диапазон.
И опять же, в предложенном тобой решении неверные (Inf/NaN) промежуточные результаты идут куда-то дальше по программе, которая к этому не готова и может забрести в страшные дебри. И отследить, где возник первый сбой, становится гораздо труднее. До результатов можно и вовсе не добраться. Какой-нибудь итерационный алгоритм может вообще зациклиться.
Не знаю, какие ты писал и налаживал вычислительные алгоритмы, что тебе оказалась предпочтительной такая логика? Я на бейсике писал, в числе прочего, численное интегрирование, интерполяцию, метод Гаусса, приближение методом наименьших квадратов... У нас целый курс лабораборок по численным методам на бейсике был. Никогда не было такого, чтобы огромной величины (на грани переполнения) числа возникали там при нормальной работе. Никогда не получал сообщения об ошибке при переполнении. Ошибки были другие. А из какого опыта берутся твои предпочтения?
На стандартном есть. Игры есть, даже динамические ("Breakout", "Ground force zero", "Dictator"). Всякие гороскопы, нумерология и др.
Последний раз редактировалось Barmaley_m; 18.11.2023 в 00:40.
Если "умник" пишет задницей, а не через стандартное API - это проблемы "умника")) Мне так кажется. Впрочем в ТО время про API не очень часто задумывались.
Сейчас тоже есть масса "умников" (даже в больших компаниях), которые пишут через "херак-херак и в продакшн". А потом ловят кайф от того, что в продакшне задница.
Так допустимо ( и даже нужно иногда для скорости) делать в макетной версии "для себя". Но если уж ПО пишется "на долгую жизнь в большом мире" - то обязательно следовать рекомендациям.
Да, можно. Как пример, программа eagle для разводки печатных плат. 2008 года выпуска. Написана ещё под х32 архитектуру.
Сейчас 2023 год. 15 лет прошло. Спокойно работает под линукс х64 у меня на компе этот самый бинарник.eagle: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.6.4, stripped
Уже сменились десятки, если не сотни версий ядра и библиотек.
Никаких виртуалок, никаких плясок с бубном. Просто запускаешь и работает. Как и в 2008м.
Так что слухи о том, что "под линуксом не запускаются бинарники" - сильно преувеличены.
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием