Просмотр полной версии : BASIC vs. Assembler
Перечислите как можно больше отличий ЯЗЫКОВ (не средств разработки!).
1. Ассемблер - есть прямой доступ к регистрам процессора.
2. Ассемблер - программист решает, где лежит программа.
3. Ассемблер - возможность создания самомодифицирующегося кода.
4. Ассемблер - значительно большая скорость выполнения команд.
А почему в названии темы обозначен BASIC? И отличие языков каких? Которые есть на спектруме или вообще?
А почему в названии темы обозначен BASIC? И отличие языков каких? Которые есть на спектруме или вообще?
Отличия Sinclair BASIC от ASSEMBLER.
На спектруме, естественно.
3. Ассемблер - возможность создания самомодифицирующегося кода.
теоретически это можно и на бейсике;)
gRAVER_ZX
08.05.2007, 15:27
почему теоретически? разве из бейсика недоступна для модифицирования та область памяти, в которой лежит код бейсик-программы?
конечно, доступна. и, например, резервируя с помощью rem определенное кол-во байт, можно потом использовать это место под что-то другое.
почему теоретически? разве из бейсика недоступна для модифицирования та область памяти, в которой лежит код бейсик-программы?
конечно, доступна. и, например, резервируя с помощью rem определенное кол-во байт, можно потом использовать это место под что-то другое.
И всё-таки пока это теоретически...
Практическая реализация, даже если она будет выполнена в показательных целях, потребует несопоставимого объёма работ.
А на примерчик, естественно, хотелось бы взглянуть :)
Практическая реализация, даже если она будет выполнена в показательных целях, потребует несопоставимого объёма работ.
как несопоставимых???
делаешь легко: вычисляешь адрес начала бейсик-программы, потом, знаешь смещение того же rem (когда прога уже дописана) и вместо rem через poke вставляешь пробел. вот тебе и изменилась программа.
другое дело, что это было никому не надо.. да и не будет..
gRAVER_ZX
08.05.2007, 16:04
ну вот ты сам не сомневаешься, что практически это возможно
тока дело еще в том, что после изменения области памяти, где хранится бейсик-прога, ее [прогу] придется перезагружать, потому что память была уже изменена и вместо rem-строки ты увидишь то, на что ее поменяла программа.
бейсик - гораздо быстрее что-то посчитать и проверить (но не всегда)
бейсик - не зависнет намертво
бейсик - проще в пронимании сути кода
как несопоставимых???
делаешь легко: вычисляешь адрес начала бейсик-программы, потом, знаешь смещение того же rem (когда прога уже дописана) и вместо rem через poke вставляешь пробел. вот тебе и изменилась программа.
другое дело, что это было никому не надо.. да и не будет..
Я не очень в курсе, но мне казалось, что программа может смещаться, при открытии дополнительных системных буферов. но я не уверен.
В принципе, на этом принципе можно интересную защиту от хакеров соорудить :)
ну вот ты сам не сомневаешься
я и не сомневался. я сомневался в том, что кто-то это делал или будет делать.
ее [прогу] придется перезагружать
ну а че? а обратно изменить в этой же проге? в конце концов, для чего-то же поменяли..
Corpsegrinder
08.05.2007, 16:20
Когда-то была у меня книжка, где приводились примеры перенумерации строк бейсик-программы, а так же примеры защит, когда пишешь в редакторе RANDOMIZE USR 0, а потом с помощью poke вставляешь в число, которое прячется за этим нулём нужное число.
Я не очень в курсе, но мне казалось, что программа может смещаться
скажем так. если работаешь с магнитофона, то адрес один. если с диска - адрес другой. можно 1 раз его узнавать, а можно каждый раз перед изменением. тогда точно не промажешь, ибо смещение остается всегда постоянное.
TaimerLan
14.05.2007, 20:24
ИМХО Ассемблер рулит и в 1000 раз быстрее работает чем Васик
И на ассемблере возможно все, что вобще возможно на спектруме. Докажите мне то ето не так
Докажите мне то ето не так
Напиши по памяти программу рисования окружности быстрее, чем на басике (в смысле программу быстрее напиши) :)
TaimerLan
14.05.2007, 21:34
Напиши по памяти программу рисования окружности быстрее, чем на басике (в смысле программу быстрее напиши) :)
Зато быстрее работать будет
В принципе, на этом принципе можно интересную защиту от хакеров соорудить
в zx-ревю 1992 (или 1993? чегой-то запамятовал...) были кое-какие примерчики, как в строку за оператором rem напичкать кое-какие фичи, которые могут сбить с толку новичка, но лишь на пару секунд задержать профессионала :)
А еще прячешь машинный код в эту строчку и сам запуск. Потом нелепыми вставками команд маш.кода (загружаешь попусту какие-то регистры всякой фигней) короче вводишь человека в заблуждение. Ну и напоследок шифруешь сам код, так что при оставновке "бряком" сразу после загрузки кода, в оперативке остается нераскодированная прога.
Nomy Graphics
15.05.2007, 11:17
Ребят, что-то вы все смешали. Всякие там REM-загрузчики, самомодифицирующийся код и т.п. - энто не Бейсик. Энто самый натуральный Ассемблер. Фактически, обсуждается классическое программирование на асме и оно же, при размещении машинной программы в Бейсик-области. Ну и где же Basic vs Asm??
По существу вопроса все было сказано верно:
Basic - для разработки некритичных к времени выполнения/памяти приложений, стоит использовать ввиду:
+ наличию встроенных математических, графических и для работы с текстом процедур и легкости обращения к ним
+ меньшим время- и трудозатратам на разработку приложения
+ более компактному и читаемому коду
+ встроенности в ОС
В остальных случаях нужен Асм ввиду:
+ максимально оптимизированного кода (по времени либо памяти, либо компромиссно)
+ возможности доступа ко все ресурсам компьютера, возможности работать с процессором напрямую, на его родном языке, не прибегая к услугам переводчика-Бейсика.
При всем том, что быстрые, красочные вещи типа динамичных игрушек, интро и дем конечно, надо писать на асме (а также системные проги, оси, утилиты), я ни в коей мере не считаю Бейсик чем-то бесполезным. И даже в свое время написал игру-симулятор (электрички) с 3D-графикой (ну псевдо- и даже псевдоквази-3D, но все же 3D) на Бейсике. Правда, и в этом случае без ассемблерных вставок не обошлось.
+ максимально оптимизированного кода (по времени либо памяти, либо компромиссно)
Важное замечание- максимально оптимизированного в меру возможностей кодера. В силу интерпретируемости васика, также относится и к нему (ибо алгоритмика она везде одинаковая).
Ребят, что-то вы все смешали. Всякие там REM-загрузчики, самомодифицирующийся код и т.п. - энто не Бейсик. Энто самый натуральный Ассемблер. Фактически, обсуждается классическое программирование на асме и оно же, при размещении машинной программы в Бейсик-области. Ну и где же Basic vs Asm??
Программа на Бейсике которая сама себя модифицирует - это не Бейсик?
По существу вопроса все было сказано верно:
Basic - для разработки некритичных к времени выполнения/памяти приложений, стоит использовать ввиду:
...
В остальных случаях нужен Асм ввиду:
+ максимально оптимизированного кода (по времени либо памяти, либо компромиссно)
В программировании, как области инженерии, оптимальные решения всегда являются компромиссными.
На мой взгляд, можно определить плюсы и минусы каждого из подходов (Бейсик и Ассемблер), а также выработать пути по взаимному использованию друг-друга. Если вызов ассемблерной процедуры из Бейсика не составляет сложностей : RANDOMIZE USR ..., то вот обратные вызовы, на мой взгляд практически нигде не используются. А ведь сколько открывается возможностей: Ассемблерная программа может динамически создать Бейсик программу, положить её в нужное место памяти, настроить системные переменные и вызвать Бейсик интерпретатор.
настроить системные переменные и вызвать Бейсик интерпретатор.
это еще зачем? проще юзать готовые процедуры пзу. так и делали всегда.
Программа на Бейсике которая сама себя модифицирует - это не Бейсик?
Пример пожалуйста, чтобы это был бэйсик.
Академический пример возможен, практически нет.
В программировании, как области инженерии, оптимальные решения всегда являются компромиссными.
Да. поиск максимума и поиск оптимума разные задачи, хотя одна через другую решается.
На мой взгляд, можно определить плюсы и минусы каждого из подходов (Бейсик и Ассемблер), а также выработать пути по взаимному использованию друг-друга. Если вызов ассемблерной процедуры из Бейсика не составляет сложностей : RANDOMIZE USR ..., то вот обратные вызовы, на мой взгляд практически нигде не используются. А ведь сколько открывается возможностей: Ассемблерная программа может динамически создать Бейсик программу, положить её в нужное место памяти, настроить системные переменные и вызвать Бейсик интерпретатор.
iS-DOS именно такой подход и использовала. И продолжает %) Если открыть руководство от Ларченко и Радионова, то там тоже предлагается такой подход - в произвольном месте лежит текст басик-программы, системные переменные подправляются и вызывается ПЗУ. Не получило распространения изза низкой эффективности, на самом деле кто использует АСМ открещивается от басика всем чем можно и если уж поддерживает, то только когда некуда деваться.
Добавлено через 22 секунды
это еще зачем? проще юзать готовые процедуры пзу. так и делали всегда.
Вот собственно про это я и говорю.
я делал сборники с FOREVER'а - там из басица вызывается асм - а потом исправляется имя загружаемого файла и выходится обратно в басиц - откуда через RUN выбранная программа запускается.... да и почти все boot'ы так сделаны... [но я в тр-дос'е если честно ничего не понимаю =)]
Nomy Graphics
16.05.2007, 10:45
Программа на Бейсике которая сама себя модифицирует - это не Бейсик?
В программировании, как области инженерии, оптимальные решения всегда являются компромиссными.
На мой взгляд, можно определить плюсы и минусы каждого из подходов (Бейсик и Ассемблер), а также выработать пути по взаимному использованию друг-друга. Если вызов ассемблерной процедуры из Бейсика не составляет сложностей : RANDOMIZE USR ..., то вот обратные вызовы, на мой взгляд практически нигде не используются. А ведь сколько открывается возможностей: Ассемблерная программа может динамически создать Бейсик программу, положить её в нужное место памяти, настроить системные переменные и вызвать Бейсик интерпретатор.
10 LET A = VAL "A"
20 PRINT A
30 POKE <адрес строки 10 + смещение до символа "А" >, RND*255
40 GOTO 10
Да, это - Бейсик. Хотя требующий уже знания устройства интерпретатора. Что не есть классический случай его применения. Но ладно, согласен.
10 POKE <адрес символа "А" в строке 20>,201
20 REM A
30 RANDOMIZE USR <адрес первого символа в строке 20>
А это - не Бейсик. Это - программирование на Бейсике машкода, т.е. асм!
Не, ну конечно, и это можно назвать Бейсиком, но просто потому, что Бейсик и Ось объединены вместе. Ведь не скажешь же, если написать RANDOMIZE USR 40000 и запустится какая-нить мегадема, что это написано на Бейсике!:v2_cool:
Далее. Оптимальные решения не всегда являются компромиссными (под компромиссом понимается баланс скорость работы/длина кода). Во многих демах, как известно, в изобилии встречается развернутый цикл, т.е. просто повторяется пара команд, вместо помещения в цикл. Тут никакого компромисса нет - все сделано ради лишних тактов - программа длинней не бывает. В системной же утилите, оси, резидентной процедуре, вирусе - упор делается на минимальный размер кода. Хотя естесственно, чаще бывает компромисс.
И про обратные вызовы - используется. Так, я использовал это в своей оси NK-DOS - именно, как ты описал.
Всё что тут рассматривается это просто программирование. Если вы напишите программу на ZX'е, в ВАСИКЕ то в любом случае её нужно будет править под другой бейсик. А если загнать программиста в ограничения, не используй вот ту сотню комманд и не трогай память, а то на калькуляторе её нет, и вообще принт не юзай, а то нет дисплея, то будет как с СИ под микроконтроллеры, одни IF'ы и FOR'ы, и то если повезёт.
Нет победителей, оба (Аsm и Васик) работают под ZX и в каждом языке есть свои особенности.
А сравнивать, что на васике можно круг нарисовать и затратить на это 0.5 минуты времени - глупо. Поскольку сама задача воссоздания лишь круга не имеет смысла ... Ну круг и в чём особеннсть языка ? Нужно ставить более обширные задачи ... Например сделать графический редактор где есть круг, линия, треугольник, элипс, кривая, всяческие меню и т.д. Вот это уже задача, и я уверен, что Васик быстро отпадёт как средство разработки.
А вот использование и васика и асма это уже более дельно. Много кода будет жраться, когжа нужно корни высчитывать, да и вообще матиматика, а через васик самое - оно !!!
Преимущество Бейсика перед ассемблером с моей точки зрения следущие:
1) его проще сделать понятным и доступным для других людей;
2) он быстрее осваивается (в том числе и благодаря тому, что он интерпретатор).
Но за все в этом мире нужно платить, и эти вот самые достоинства совершенно определяют и его недостатки.
Adramelek
19.06.2007, 00:27
Перечислите как можно больше отличий ЯЗЫКОВ (не средств разработки!).
1. Ассемблер - есть прямой доступ к регистрам процессора.
2. Ассемблер - программист решает, где лежит программа.
3. Ассемблер - возможность создания самомодифицирующегося кода.
4. Ассемблер - значительно большая скорость выполнения команд.Как можно сравнивать тёплое с мягким? Одной фразы "Команды языка ассемблера один в один соответствуют командам процессора" достаточно, IMHO. Хотя, если кому-то всё ещё интересно...
http://ru.wikipedia.org/wiki/%D0%AF%D0%B7%D1%8B%D0%BA_%D0%B0%D1%81%D1%81%D0%B5% D0%BC%D0%B1%D0%BB%D0%B5%D1%80%D0%B0
http://ru.wikipedia.org/wiki/Basic
Southern Bear
19.06.2007, 06:52
программирование на Бейсике машкода, т.е. асм!
Не совсем так. Васиц - интерпретатор или компилятор. Ассемблер - компилятор. А маш.код, он и есть маш.код. Он не требует интерпретации или компиляции. Ассемблер != маш.код.
Shadow Maker
19.06.2007, 08:38
Короче на спектруме встроенный басик не жилец как средство разработки серьезных программ, ибо это сопряжено с большим количество нервов и общей тормознутостью полученной программы. Ассемблер наиболее эффективен, с вызовами ПЗУ для вычислений или чего еще потребуется...
James DiGreze
20.06.2007, 05:48
Использовать то можно, и иногда очень даже эффективно, особенно если заюзать вставки маш.кода.
mishutka
20.06.2007, 06:29
весь basic vs assembler свелся к тому что пишем на ассемблере но калькулятор юзаем басиковый
Сам противостояние имхо неверное... нельзя так противопоставлять.
Бейсик это бейсик - ЯВУ если угодно, со всеми своими достоинствами и недостатками. А сранивать ЯВУ и машинный код, коим в целом и является ассемблер можно бесконечно очевидно одно - машинный код быстрее, ЯВУ более удобный для написания программ (ну вот вывести симвом на экран это показатель этих двух средств).
Сильно сомневаюсь чтобы спекковский басяк сильно отличался от общего прототипа ЯВУ.
Зато вот что интересно, так это использование в бейсик программах вставок маш. кода, но не таким дурацким способом как это делалось, а через вызов посредством USR и DEF FN (который насколько я знаю редко пользовался программисткой братвой). Откройте Ревюшки от 95 года и статьи Вадима Бодрова по растровой графике - там он предлагал эффективно соединять бейсик и маш. код - первый делает обсчёты (которые, при всём желании, быстрее никак не сделать) второй выводит графику, и можно в итоге получить нечто не очень слабое. Вроде как одна из фирменных игрушек использовала такой подход - когда все тексты выводится и рассчёты проводятся через басик а графика через маш. код.
если писать на ассемблере даже при использовании чисто ПЗУшных процедур (печать символа, векторная графика, рассчеты на калькуляторе) - разница с бейсиком на порядок, если не больше... единственное, что - конечно на басике гораздо проще чтонить накидать и глянуть, что получится... я вот к примеру простые таблички для дем до сих пор на бейсике рассчитываю =)
но когда я все еще сидел на реале, я специально такие рассчеты делал в асме с использованием ПЗУшного калькулятора - это в UNREAL есть NUMLOCK =), а на реале 5 минут вместо 1 сидеть очень тяжко - особенно на этапе экспериментирования, когда не знаешь толком что надо получить...
эффективно соединить бейсик с машкодом это не эффективно =) слишком слабый проц - и слишком неэффективно бейсик работает... простой пример "1 BORDER 1:BORDER 0:GO TO 1" и "ld a,1: out (#fe): ld a,0: out (#fe): jr $-8" - сравните количество полосок ;)
при необходимости возможно написание быстрой математики в ассемблере - только каких человекозатрат это потребует? в нашей последней деме есть 2 части, где рассчитывается расстояние отрезков ( len=sqr(x*x + y+y) ) - для каждой из 16 точек выссчитываются расстояния до всех остальных - 240 вычислений отрабатываются меньше чем за 30К тактов =) но эт конечно чисто демошный частный случай :v2_laugh:
Про компиляторы бэйсика забыли (Tobos FP, Softek, MCoder2)
:(
Теоретически, если в бэйсик был бы заложен компилятор и ключи запуска, такие как:
1. Выполнить в режиме интерпретации (возможен останов и отладка).
2. Выполнить, предварительно скомпилировав (адрес такой-то).
то вопрос быстродействия не стоял на первом месте.
Тогда бы обсуждалось качество встроенного компилера.
Затем, в бэйсике нет вставки ассемблерных команд. Можно, конечно, вводить цифры (например в STC1), но это уже не то (как упоминал выше Nomy Graphics).
А вот неплохой бы вариант:
<...>
20 BORDER 0
30 PRINT PAPER 3; INK 6; AT 5,8;"Loading, don't stop the tape please..."
40 LD IX,16384
50 LD DE, 6912
60 LD A,255
70 SCF
80 CALL 1366
<...>
8-)
зы: ну, я опускаю тот момент, что текст асма нужно как-то отделить.
Не так всё было, не так...
Про компиляторы бэйсика забыли
самый ништяк компилятор, которым я пользовался - HiSoft BASIC.
James DiGreze
17.10.2007, 08:18
Vovoi, ну, в принципе можно написать некий "компилятор" асма для работы из-под бейсика в стиле:
10 RANDOMIZE USR address_of_compiler: REM "LD IX,16384: LD DE,6912: LD A,255: SCF: CALL 1366"
ЗЫ: Кстати, было бы прикольно!
Vovoi, ну, в принципе можно написать некий "компилятор" асма для работы из-под бейсика в стиле:
10 RANDOMIZE USR address_of_compiler: REM "LD IX,16384: LD DE,6912: LD A,255: SCF: CALL 1366"
ЗЫ: Кстати, было бы прикольно!
А если так:
<...>
310 REM asmstart
320 REM LD A,2; kommenty rulyat :)
340 REM CALL 5633
350 REM ;nu i tak dalee
310 REM asmend
<...>
... для удобочитаемости.
:)
хотя, наверное ерунда это все... проще на асме написать :)
Добавлено через 1 час 1 минуту
А,.. я понял в чем была фишка строки "10 RANDOMIZE USR address_of_compiler:". В том, чтобы в "Basic RealTime", т.е. в процессе интерпретации уже выполнялась только что скомпиленная часть программы (бэйсик-строка), которая впоследствии будет просто размещена в теле будущей программы. Но эти сладости увеличат объем компилятора :(
Кстати, о расширителе бэйсика "Laser Basic" говорилось, что кроме интерпретации, сей продукт может компилировать также листинги зашитого бэйсика. Таким образом, программа управлялась со смесью SpectrumBasic и LaserBasic.
Н.Родионов, А.Ларченко "Диалекты Бэйсика для ZX Spectrum". Компилятор. Стр186.
ЗЫ:
В моем bas-примере не было одной фишки: POKE 23606,64256. Помню, как-то надоело делить на 256 (в оперативке было 4 разных шрифта), да потом еще что-то прибавлять. Так что взял, да влючил в компилер новый оператор. :)
Powered by vBulletin® Version 4.2.5 Copyright © 2024 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot