Почему компилированный Бейсик выполняется быстро?

[Lethargeek]

Вообщето, Бейсик ОЧЕНЬ плохой язык для обучения.
Функций нет, структуры нет.. Ну что-то вроде "ассемблера для домохозяек". Типа пишу что и как в голову придёт, а там если что ошибку выдаст.
Вот Pascal - это да. Для обучения. Строгие типы. Структура.

для всего плохой, кроме "хоть какой-то я(о)ву на очень слабом железе"
а для обучения лучше лого (правда, реализация именно на спектруме странноватая)
паскаль подразумевает компиляцию и 48k ему маловато

Lethargeek, нумерация строк, неизбежное зло.

да ну, на ресурсах спека (и многих прочих восьмибиток 80-х) вполне избежное
а теперь представь, что от строчных номеров ты избавился, а else нету

С другой стороны, это куда проще, чем запоминание названия меток.

лучше помнить имена процедур)

[null_device]

а теперь представь, что от строчных номеров ты избавился, а else нету

Ну, нету, и нету. После конструкции, IF THEN, пишем что хотим выполнить по условию и делаем GOTO + несколько строк. А в промежутки между этими строками пишем, то что должно выполниться по условию ELSE.

лучше помнить имена процедур)

Вкусовщина и сила привычки. Мне было проще запомнить двух-трёх-четырехзначный номер строки с подпрограммой.

[Lethargeek]

Ну, нету, и нету. После конструкции, IF THEN, пишем что хотим выполнить по условию и делаем GOTO + несколько строк. А в промежутки между этими строками пишем, то что должно выполниться по условию ELSE.

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

[null_device]

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

[Barmaley_m]

Точка входа TR-DOS #3D13 не содержала всех тех функций "форматирование, чтение и анализ дорожек" и прочих. То есть налицо недостаток функционала API.
Если бы всё это было - то особо никто бы и не лазил "напрямую в регистры".

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

Любой драйвер предоставляет меньше возможностей, чем то, на что способно железо. Хотя бы потому, что некоторые трюки с этим железом могли быть неизвестны на момент создания драйвера. Типа как использование AY-огибающей. Изначально она предназначалась для медленного управления громкостью, и только потом ее научились использовать для создания особых тембров.

Авторы TR-DOS тронулись бы умом, если бы их заставили написать универсальное API для форматирования дисков произвольным образом или создавать/проверять защиты от копирования. Разработка заняла бы столько времени, что какая-то другая фирма выпустила бы подходящий для запуска игр контроллер дисковода раньше. И был бы у нас не Beta-Disk, а Theta-Disk. С не менее, а то и более улылым софтом, чем TR-DOS.

И даже если мега-универсальное API создать - то оно не подойдет тем, у кого мало места в памяти. ПЗУ или ОЗУ - оно денег немалых стоило.

Тем более, что никакого выигрыша в скорости в данном случае это не даёт.

Конкретно в случае TR-DOS - даёт. Программы, использующие самописные процедуры чтения секторов, читают с диска раза в полтора быстрее, чем те, которые используют API.

Сейчас создателям ПО и в голову не придёт "лезть напрямую в регистры" видяхи или звуковухи. За исключением драйверописателей.

Это потому, что зоопарк железа большой. К тому же, железо долго не живет, постоянно новое появляется. Если бы железо было константным, как во времена Спека - то лезли бы в регистры, как миленькие. Потому, что это давало бы конкурентные преимущества.

У спектрума видеопамять была "константой". Потому в неё безбоязненно лазили напрямую. Плюс скорость. В вот если был десяток видюшек, да разных... То фиг бы там куда лазали помимо API.

Вот в мире CP/M был большой зоопарк железа, и там почти все работали через API, каким бы убогим и тормозным оно ни было. По тем же причинам на этих системах не было красивой графики и динамичной анимации.

[Lethargeek]

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

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

[andrews]

К тому же, железо долго не живет, постоянно новое появляется

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

- - - Добавлено - - -

По тем же причинам на этих системах не было красивой графики

а разве она хоть какая-то была?

[SfS]

Lethargeek, нумерация строк, неизбежное зло. С другой стороны, это куда проще, чем запоминание названия меток. И снижает вероятность ошибки. Оттого, я например, не использовал многосимвольные переменные.

Ну да. Запомнить метку screen_loop_begin сложнее, чем номер 1278 ?)

- - - Добавлено - - -

для всего плохой, кроме "хоть какой-то я(о)ву на очень слабом железе"
а для обучения лучше лого (правда, реализация именно на спектруме странноватая)
паскаль подразумевает компиляцию и 48k ему маловато
да ну, на ресурсах спека (и многих прочих восьмибиток 80-х) вполне избежное
а теперь представь, что от строчных номеров ты избавился, а else нету
лучше помнить имена процедур)

Есть бейсики с процедурами и else и while и прочим.. И на спеке тоже. Вопрос реализации.

- - - Добавлено - - -

Вот в мире CP/M был большой зоопарк железа, и там почти все работали через API, каким бы убогим и тормозным оно ни было. По тем же причинам на этих системах не было красивой графики и динамичной анимации.

Так там и стандартов на графику, как мне помнится, не было.

[Conan]

Вообщето, Бейсик ОЧЕНЬ плохой язык для обучения.

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

Софи Уилсон (Acorn) за год возни (это только в фильме недельку повкалывали, выиграли конкурс, хлопнули шампанским и уже компьютер презентуют) написал(а) очень быстрый Бейсик со всякими IF THEN ELSE. А потом его несколько лет доделывали и в прайм-тайм по телевизору показывали и в школы усиленно пихали. Помогло это стать самым-самым? Не очень. Проиграл BBC-Бейсик в популярности "ограниченной" и недоделанной версии от Клайва Синклера, а в массовости еще и Бейсику от Майкрософта. И это несмотря на гос. поддержку и навязчивую массовую рекламу. Ошибок в BBC-Бейсике тоже немало. ПЗУ вдвое большего объема (по сравнению с ZX Spectrum) под него требовалось.

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

Кстати, напомню, что версия Бейсик 48К которая разошлась с оригинальными ZX Spectrum и клонами была урезанной Бета-версией. Более полная оригинальная (от Викерса) Альфа-версия (с ошибками, но с доп. расширениями Бейсика) тоже сохранилась. На скрепке ее бинарник.
ZX-Spectrum-Prototype.rar

[SfS]

Судить современными мерками софт сорокалетней давности не очень корректно.

Но мы то сейчас как раз и пытаемся оценить + и - данного васика с современной точки зрения. Понятно, что в ТО время были иные представления. Точнее, я бы сказал, отсутствие представлений даже)