можно попробовать как-то то снять трассу выполнения интерпретируемой и компилированной программы - но подозреваю что под это надо ещё инструменты писать.Цитата:
Сообщение от mmxdmv
Вид для печати
можно попробовать как-то то снять трассу выполнения интерпретируемой и компилированной программы - но подозреваю что под это надо ещё инструменты писать.Цитата:
Сообщение от mmxdmv
Только это был не Ленин, а временное правительство. И не в 1918-м году, а в 1917-м. А вообще, данная реформа русского языка готовилась ещё при царе и людьми, далёкими от большевизма и революционной деятельности.Цитата:
. Даже В.И.Ленин, который в 1918 отменил некоторые буквы, на букву 'ё' не покусился
mmxdmv, вроде как tobos, использует свой калькулятор и формат хранения чисел ("Диалекты Spectrum-бейсика", изд. Питер).
Попутно, накладывается ограничение на некоторые операторов (где-то полностью, в других случаях, частично теряем ряд фукций операторов).
А если использовать целочисленные компилляторы, прирост скорости выполнения получается еще больше.
...что потребует радикально изменить формат хранимой бейсик-программы и потянет за собой дальнейшие переделкиЦитата:
Сообщение от mmxdmv
Разница громадная, примерно как с парсером и без парсера. Интерпретатор обрабатывает дерево выражений, всегда проверяя синтаксис и тип значений. Компилятор уже знает порядок выражений и делает вызовы калькулятора подряд. Без проверки синтаксиса, типов выражений и много еще чего.Цитата:
Сообщение от mmxdmv
Вот и сейчас надо не лениться и почитать комментарии к интерпретатору (1b8a) и, возможно, калькулятору (335b) - это не "Война и мир" авось. И тут же найдутся ответы на все вопросы.Цитата:
Сообщение от mmxdmv
Нормальный Васик на Спектруме был. Когда быстродействия не хватало, но память свободная оставалась - тоже пользовался этим
https://en.wikipedia.org/wiki/ToBoS-FP
На фоне других Бейсиков - спекковский был нормальным компромиссом между точностью и скоростью вычислений (для 8-и битных машин). Кстати - автору темы можно попробовать ToBoS для своей программы - должно быть быстрее :)
это конечно хорошоЦитата:
Сообщение от Mx_Serg
но по моему ему при этом самому нужно было находится в памяти в месте с скомпилированной программой
а еще была интересная возможность
скомпилировать и вызывать из другой бейсиковской программы
токо уже не помню как из этого тобоса возвращаться обратно
как то возвращался (может просто go to на адрес больший самого последнего?)
и бейсиковские адреса у обоих программ пересекались :v2_dizzy_turn:
не помню сохранялись ли переменные после этого :v2_conf2:
Правильно помните. Ему, как и почти всем, требовалось находиться в памяти при компиляции и работе скомпилированного блока.Цитата:
Сообщение от NEO SPECTRUMAN
Целочисленный MCoder2, Евдокимова в этом отношении был куда интересней.
По команде оператора STOP. ЕМНИП, компиллятром она не воспринималась как конец программы.Цитата:
Сообщение от NEO SPECTRUMAN
интересно:v2_dizzy_step:Цитата:
Сообщение от null_device
но я стоп никогда не юзал для этого
Недавно я делал сравнительный замер секундомером времини выполнения этой простой BASIC-программы в эмуляторе BBC Micro (BeebEm 4.14, эмуляция BBC Model B в реальном времени) и в эмуляторе UnrealSpeccy (эмуляция в 128 BASIC тоже в реальном времени).
Результат меня удручил: соответственно 1,7с и 3,2с, - не в пользу Спектрума.Код:10 FOR N=1 TO 50
20 LET A=COS (N)
30 NEXT N
40 PRINT A
На Энтерпрайзе ещё больше: ≈5с. (ещё в год анонса большинство рецензентов говорили, что бейсик тормозной)Цитата:
Сообщение от Grand
MSX на Z80 посчитает за 4 сек (но у него точность выше), про Enterprise уже сказали. Вот Color Computer 2 на Motorolla 6809 справляется за 2 сек. и это при частоте меньше 1 MHz.
Мне кажется, именно выполнение самой команды, например, BORDER идёт очень быстро, а большую часть времени тратится на вычисление выражения. Разница по времени выполнения между BORDER 3 и BORDER x*2 довольно большая, что говорит в пользу этой версии. Да, наверное, можно было оптимизировать так, чтобы при наличии только одного явно указанного числа блок вычисления выражения не вызывался, а выдавалось это готовое число. Наверное, посчитали это бессмысленной оптимизацией на фоне остальных тормозов.
Бейсик не такой уж и медленный для своего времени. По сравнению с конкурентами (Apple ][, Atari, C64, MSX) работал весьма на уровне. РКшный бейсик был и того медленнее. Большинство этих бейсиков были токенизированные. Хотя и "прозрачно" для пользователя - тот не видел, что внутреннее представление программы имеет токены.
Я внимательно изучал дизассемблер ПЗУ. Конечно, большого упора на оптимизацию по скорости там не делалось, но и явных ляпов тоже нет (кроме, разве что, CIRCLE). По большей части, проводилась оптимизация по размеру кода. И тут важен не только объем доступного ПЗУ, но и ограниченность адресного пространства Z80. Если бы для бейсика потребовалось не 16, а 32К - то столько же было бы откушено от легкодоступного ОЗУ, либо пришлось бы переключать страницы. А это потребовало бы аппаратной логики, которая в те годы была на вес золота. Найденный разработчиками баланс оказался очень удачным, чему свидетельство - успех проекта. И провал последующих проектов (Sinclair QL), где "золотая середина" найдена не была.
Есть компилятор Laser Basic. Не знаю, как именно он работает; судя по звуку компилированных программ при записи на ленту, там как раз и идет преобразование в пи-код. По памяти впечатлений, которые я получил, когда игрался с этим компилятором 25 лет назад, ускорение было довольно существенным.