Подскажите пожалуйста, На каких языках пишутся игры. [Архив] - Speccy

Barmaley_m

06.01.2011, 21:10

Как ни смешно, но на ассемблере писать игры не сложнее чем на бейсике.
На ассемблере все-таки писать сложнее по следующим причинам:
1) Ошибки в программах имеют тяжелые последствия, вплоть до сброса компьютера. Раньше, когда программы сохранялись на кассетах, это серьезно задерживало процесс, пока перемотаешь кассету и загрузишь заново ассемблер и свою программу, а потом еще надо было внести в нее все те последние изменения, которые были уничтожены в результате сброса. Сейчас все грузится быстрее, но все равно, если забыл сохранить текст программы перед запуском - придется сочинять его заново. То же касается компиляторов: ошибки в компилированных программах часто приводят к сбросу компьютера.
2) Невозможно остановить в любой момент ассемблерную программу и посмотреть ее состояние с той же легкостью, как это можно сделать с бейсик-программой.
3) Некоторые ошибки в программах на ассемблере поздно себя проявляют, делая трудным их обнаружение.
4) Отсутствие разборщика выражений, из-за этого - трудности с вычислениями. Арифметика с плавающей точкой доступна начинающим только после изучения пи-кода бейсиковского "калькулятора", что сопоставимо по сложности с изучением самого ассемблера.
5) Отсутствие процедур ввода и вывода. Использование бейсиковских процедур требует изучения и понимания куда более сложных вещей, чем то, как пользоваться операторами PRINT и INPUT.

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

---------- Post added at 21:10 ---------- Previous post was at 21:07 ----------

Бейсик вреден. Начинать нужно с кросс-ассемблера или кросс-компилера на пц.
Чем вреден бейсик?

Я, профессиональный программист, начинал с бейсика, и не вижу в этом никакого вреда.

Vitamin

06.01.2011, 21:16

Я, профессиональный программист, начинал с бейсика, и не вижу в этом никакого вреда.
Если вовремя с этого бейсика уйти. А не изобретать способы почесать левое ухо правой пяткой.

А для написания игр, имхо, стоит поискать специализированные программные пакеты.

goodboy

06.01.2011, 21:43

для написания игр, имхо, стоит поискать специализированные программные пакеты.

недавно наткнулся на ещё один - называется White Lightning.
http://www.worldofspectrum.org/infoseekid.cgi?id=0008967

Spectramine

06.01.2011, 21:59

Бейсик для начинающих имхо лучший вариант чтобы почувствовать, что такое программирование вообще. А вреден недостаточными средствами структурирования программ и данных, что провоцирует спагетти-стиль программирования.

Segfault

06.01.2011, 22:09

Удобно на смеси асма и ц. Жаль кроме hi-soft'овского 198.. г никто так и не прикололся на норм, редактор/компилер C под спек, а ведь была бы классная софтина. Если религия позволяет, можно заюзать pc-кросскомпилеры z88dk/sdcc.

Lethargeek

07.01.2011, 00:36

1) Ошибки в программах имеют тяжелые последствия, вплоть до сброса компьютера. Раньше, когда программы сохранялись на кассетах, это серьезно задерживало процесс, пока перемотаешь кассету и загрузишь заново ассемблер и свою программу, а потом еще надо было внести в нее все те последние изменения, которые были уничтожены в результате сброса. Сейчас все грузится быстрее, но все равно, если забыл сохранить текст программы перед запуском - придется сочинять его заново
если ты забыл "сохранить текст программы перед запуском"
то не сможешь даже загрузить снапшот в эмулятор для трассировки :D

2) Невозможно остановить в любой момент ассемблерную программу и посмотреть ее состояние с той же легкостью, как это можно сделать с бейсик-программой
Лолшто? С эмулятором отлаживать машинный код ПРОЩЕ бейсика!

3) Некоторые ошибки в программах на ассемблере поздно себя проявляют, делая трудным их обнаружение
На бейсике та же хрень, быстро ловятся только синтаксические ошибки и опечатки

4) Отсутствие разборщика выражений, из-за этого - трудности с вычислениями. Арифметика с плавающей точкой доступна начинающим только после изучения пи-кода бейсиковского "калькулятора", что сопоставимо по сложности с изучением самого ассемблера.
Чушь - все давно придумано до нас, просто бери готовенькое
Даже лучше где-нибудь стырить процедуры, бо калькулятор глючный
Только нафиг начинающему игроделу вещественная арифметика?
Сразу прям Элиту чтоль переплюнуть?

5) Отсутствие процедур ввода и вывода. Использование бейсиковских процедур требует изучения и понимания куда более сложных вещей, чем то, как пользоваться операторами PRINT и INPUT.
Что такого запредельно сложного в каком-то rst10? :rolleyes:
А не нравится - опять же, возьми готовое (или даже лучше начать с написания своих)

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

Чем вреден бейсик?
Вот именно тем и вреден, что потом приходится отучать от "простых вещей" :p

Spectramine

07.01.2011, 00:48

Интересно, найдётся кто-нибудь, кто начинал программировать сразу на асме :)

Или хотя бы не на бейсике (калькулятор не в счёт).

moroz1999

07.01.2011, 01:33

Сейчас все грузится быстрее, но все равно, если забыл сохранить текст программы перед запуском - придется сочинять его заново.SJASM: редактируем на PC, делаем простенькую автосборку - по запуску bat-файла всё само компилируется и запускается в эмуляторе. При сбросе ничего не теряется.

2) Невозможно остановить в любой момент ассемблерную программу и посмотреть ее состояние с той же легкостью, как это можно сделать с бейсик-программой.Опять-таки поможет эмулятор. В Unreal более чем достаточный debugger - нажал escape и ковыряйся в программе в своё удовольствие :)

3) Некоторые ошибки в программах на ассемблере поздно себя проявляют, делая трудным их обнаружение.Не соглашусь! Это касается любой сложной программы - чем сложнее структура, тем больше таких ошибок. Просто ассемблер позволяет писать более сложные программы, поэтому в них более сложные баги.

Со всем остальным соглашусь.
Советую определить цель:
1. Если цель - научиться программировать, то лучше начать с бейсика.
2. Если цель - написать игру, то лучше на бейсик время не тратить, т.к всё равно в итоге придется осваивать весь асм со всеми сложностями - так зачем делать двойную работу?

Это, естественно, имхо.

---------- Post added at 00:29 ---------- Previous post was at 00:23 ----------

Интересно, найдётся кто-нибудь, кто начинал программировать сразу на асме :)Я точно помню, что начал асм изучать до того, как освоил смысл бейсиковских команд for, if и прочей базы. Максимум, что умел - цвет экрана поменять и файлы с диска подгрузить.
Учился по книге "Как написать игру" с робокопом - там хреново всё объяснялось, но мне хватило, чтобы хоть что-то зашевелилось на экране.

Не припомню, чтобы это что-то изменило - высокоуровневые управляющие структуры всё равно пришлось учить, но это уже были C, паскаль итд. На бейсике до сих пор их синтаксиса не знаю. Короче, мысль такая, что без бейсика не легче и не сложнее, если цель - освоить основы assembler'а.

---------- Post added at 00:33 ---------- Previous post was at 00:29 ----------

В общем, что я опять остро почувствовал - новичкам требуется Wiki по программированию - от статей по сборке и отладке до готовых примеров и мини-библиотек.
Мне, причем, самому - в первую очередь :D

Lethargeek

07.01.2011, 02:10

1. Если цель - научиться программировать, то лучше начать с бейсика.
Если просто "программировать вообще", то не с бейсика и даже не со Спека :D

BYTEMAN

07.01.2011, 02:14

Из частично бейсиковских можно вспомнись игрушки-стратегии от CCS: Blitzkrieg, Overlord.

Barmaley_m

07.01.2011, 03:14

А вреден недостаточными средствами структурирования программ и данных, что провоцирует спагетти-стиль программирования.
Ассемблер ничем не лучше бейсика с этой точки зрения. А даже и хуже. В бейсике есть хотя бы именованные переменные, массивы, строки, циклы наконец. Они придают программе и данным хоть какую-то структуру.

Я не против ассемблера, просто возражаю против того, что на нем легче программировать, чем на бейсике.

---------- Post added at 03:14 ---------- Previous post was at 02:42 ----------

SJASM: редактируем на PC, делаем простенькую автосборку - по запуску bat-файла всё само компилируется и запускается в эмуляторе. При сбросе ничего не теряется.
Я вообще-то имел в виду не кросс-компиляцию, а работу с ассемблером в эмулируемой системе (или на реале). Но даже если писать программу с прицелом на эмулятор: видишь, ты сам описал, сколько всего нужно. Какие-то bat-файлы создавать, стыковать ассемблер с эмулятором. С бейсиком проще. Там всё сразу есть. Не надо изучать доки к куче других программ. И программа на бейсике (если только она не делает какие-нибудь POKE или USR) не может привести к сбою компьютера.

И опять-таки: допустим, произошел сбой при пробном выполнении программы на ассемблере. Как в этом случае можно проследить его причину, если память перепахана? Бейсик же обычно останавливается с ошибкой, потому что там проверки постоянные на выход за пределы диапазона, NEXT без FOR и так далее.

Опять-таки поможет эмулятор. В Unreal более чем достаточный debugger - нажал escape и ковыряйся в программе в своё удовольствие :)
Это все ничто по сравнению с преимуществами, которые предоставляют интерпретируемые языки типа бейсика. При останове программы в них можно распечатать любые данные, можно выполнять сложные команды этого языка или куски отлаживаемой программы, вычислять выражения. Изменить текст программы и продолжить ее работу. Всего этого в отладчиках компилируемых языков нет, даже отладчик Visual C++ сильно ограничен в своих возможностях к копанию в программе, что уж говорить об отладчике Unreal.

Не соглашусь! Это касается любой сложной программы - чем сложнее структура, тем больше таких ошибок. Просто ассемблер позволяет писать более сложные программы, поэтому в них более сложные баги.
Видишь ли, я имел в виду такие ошибки, которые не сами по себе приводят к сбою, а портят где-нибудь содержимое памяти, так что программа сбивается спустя долгое время в другом месте. При программировании на бейсике вероятность подобных ошибок уменьшается, так как во-первых, имеются именованные переменные, и при присвоении переменной A нельзя испортить переменную B. Во-вторых в бейсике постоянно происходят проверки на предмет выхода за пределы диапазона и другие ошибки времени выполнения. Просто посчитай, сколько всего разных ошибок диагностируется бейсиком (сообщения 1-9, A-R). По сравнению с этим, сколько ошибок диагностируется ассемблером? Только две! Программа либо правильно работает, либо слегка глючит, либо компьютер полностью сбивается. А на бейсике больше вероятность останова программы с диагностикой на ранних стадиях ее выхода из-под контроля.

2. Если цель - написать игру, то лучше на бейсик время не тратить, т.к всё равно в итоге придется осваивать весь асм со всеми сложностями - так зачем делать двойную работу?
Это смотря какую игру. Начинающий программист, думаю, не потянет работу класса Sea Dragon, например. Такой программист должен понимать ограниченность своих возможностей и начать с чего-нибудь попроще, вроде тех примеров, что ранее приводились в этой ветке. Простую же игру не только можно, но и нужно писать на бейсике. Это быстрее приводит к успеху.

Маленькие успехи способствуют поддержке энтузиазма и стремлению к большим успехам. Рано или поздно человек сам осознает ограниченность бейсика и потянется к чему-нибудь более серьезному. Ведь почти все из нас этот путь прошли, так зачем от него отваживать новичков?

psb

07.01.2011, 03:40

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

а научиться можно на ... демках! и себе польза, и ААА радость! попробуешь чего-нить такого по экрану погонять, сразу поймешь кучу фишек и осознаешь что можно потянуть, а что не очень.

Spectramine

07.01.2011, 03:54

Я не против ассемблера, просто возражаю против того, что на нем легче программировать, чем на бейсике.

Новичку точно не легче. Да и вообще программирование на ассемблере более трудоёмко. Исключение - случаи, когда задача хорошо укладывается в имеющиеся ассемблерные наработки в виде готовых процедур и макросов.

Ассемблер ничем не лучше бейсика с этой точки зрения. А даже и хуже. В бейсике есть хотя бы именованные переменные, массивы, строки, циклы наконец. Они придают программе и данным хоть какую-то структуру.
Ассемблер дисциплинирует мышление в плане структурирования программ лучше, чем бейсик, потому что без процедурного структурирования даже небольшую игру на ассемблере просто не напишешь. На бейсике - вполне. Мало того, в плане визуального структурирования ассемблер лучше бейсика - отступы, пустые строки, комментарии-шапки процедур и циклов. На zx-бейсике длинные строки, без которых чаще всего не обойтись, визуально рвут текст программы, делая отступы бесполезными (к тому же пробелы и комментарии в тексте тормозят выполнение). Так что в целом бейсик всё-таки больше, чем ассемблер, поощряет неупорядоченный стиль программирования. По крайней мере zx-бейсик, очень близкий к чистому бейсику. Я сужу по себе - какие хитрозаплетённые и трудночитаемые программы я когда-то писал на бейсике, и как естественно приходилось структурировать программу на ассемблере.

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

psb

07.01.2011, 05:47

какие хитрозаплетённые и трудночитаемые программы я когда-то писал на бейсике, и как естественно приходилось структурировать программу на ассемблере.
просто ты не писал хитрозаплетенных программ на ассемблере, вот и вся разница. если говорить о структурном программировании, то ассемблер - это зло злейшее! он разрешает делать вообще ВСЁ, что только можно, и неокрепший ум и будет делать ВСЁ. никогда у него не будет хорошо структурированной программы, ибо поймет он прелести экономии кода, прыгая в кусок другой процедуры, мухлеж со стеком, патч кодом самого себя (как минимум хранение переменной в самой команде) и т.д.

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

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

Lethargeek

07.01.2011, 06:49

Я вообще-то имел в виду не кросс-компиляцию, а работу с ассемблером в эмулируемой системе (или на реале)
А зачем? Вот сегодня, начинающему - зачем?

Но даже если писать программу с прицелом на эмулятор: видишь, ты сам описал, сколько всего нужно. Какие-то bat-файлы создавать, стыковать ассемблер с эмулятором.
Ну не создавай, не стыкуй. Ручками грузить снапшот все умеют.

С бейсиком проще. Там всё сразу есть.
Даааа, все сразу? Как насчет локальных переменных? Структур? Указателей? :v2_conf2:

И программа на бейсике (если только она не делает какие-нибудь POKE или USR) не может привести к сбою компьютера.
Еще как может, например из-за неаккуратного обращения с каналами
Но чем, собс-но, так страшен сбой виртуального компа в эмуляторе? :D

И опять-таки: допустим, произошел сбой при пробном выполнении программы на ассемблере. Как в этом случае можно проследить его причину, если память перепахана? Бейсик же обычно останавливается с ошибкой
...проследить первоначальную причину которой ничуть не проще
Самые поганые логические ошибки приходится ловить трассировкой
А на бейсике? Стопы с ремами ручонками забивать? :v2_dizzy_tired2:

Это все ничто по сравнению с преимуществами, которые предоставляют интерпретируемые языки типа бейсика. При останове программы в них можно распечатать любые данные, можно выполнять сложные команды этого языка или куски отлаживаемой программы, вычислять выражения.
При отладке в эмуляторе это попросту НЕ НУЖНО (хотя можно) - И ТАК ВСЕ ВИДНО

Видишь ли, я имел в виду такие ошибки, которые не сами по себе приводят к сбою, а портят где-нибудь содержимое памяти, так что программа сбивается спустя долгое время в другом месте
Так на бейсике ровно то же самое с переменными

При программировании на бейсике вероятность подобных ошибок уменьшается, так как во-первых, имеются именованные переменные, и при присвоении переменной A нельзя испортить переменную B.
Ты не поверишь, в ассемблерах они тоже есть :v2_dizzy_biggrin2:
А еще там есть именованные процедуры, структуры, макросы...

Во-вторых в бейсике постоянно происходят проверки на предмет выхода за пределы диапазона и другие ошибки времени выполнения
Ну забей в макруху явную проверку диапазона
Или точку поставь контрольную

Это смотря какую игру. Начинающий программист, думаю, не потянет работу класса Sea Dragon, например
Ну ты хватил, начинающий даже маникмайнера ниасилит, пусть питона пишет :)

просто ты не писал хитрозаплетенных программ на ассемблере, вот и вся разница. если говорить о структурном программировании, то ассемблер - это зло злейшее! он разрешает делать вообще ВСЁ, что только можно, и неокрепший ум и будет делать ВСЁ. никогда у него не будет хорошо структурированной программы, ибо поймет он прелести экономии кода, прыгая в кусок другой процедуры, мухлеж со стеком, патч кодом самого себя (как минимум хранение переменной в самой команде) и т.д.
Ерунда. Выкрутасы в структурирующей части просто бессмысленны, в мелких процедурках - безвредны.
Главное, что в асмах ЕСТЬ достаточные средства структурирования, а в синклер-бейсике НЕТУ

Но для того, чтобы начать мыслить программистскими категориями, начать учиться программированию - имхо, бейсик вне конкуренции
"Студентов, ранее изучавших Бейсик, практически невозможно обучить хорошему программированию. Как потенциальные программисты они подверглись необратимой умственной деградации" (c) Э.Дейкстра ;)

Если уж приспичило учиться программированию с нуля непременно на Спектруме - начинайте хотя бы с бета-мега-бейсиков, а еще лучше - с Лого (тем более, что Инфорком, помнится, печатал в ZX-ревю перевод учебника), он куда удобней и дружелюбней. Да, они жрут память - но обычному-то бейсику все равно от свободной памяти проку мало, для больших проектов он практически непригоден.

psb

07.01.2011, 07:24

Даааа, все сразу? Как насчет локальных переменных? Структур? Указателей?
ничего такого в ассемблере НЕТ :)
а я и в спектрумовском бейсике могу сделать РЕКУРСИЮ, это не значит что он поддерживает рекурсии.

Еще как может, например из-за неаккуратного обращения с каналами
приведите-ка пример без poke и usr, убивающий все безвозвратно? ;)))))

Так на бейсике ровно то же самое с переменными

нет не то же самое. присваивая что-то переменной А, В никогда не попортишь. а в ассемблере не тока В испортишь легко, а еще и сам код! а на реалах было и диск убивался от случайного перехода не туда...

А еще там есть именованные процедуры, структуры, макросы...
слишком сложно... мощно, но сложно;)

Ну забей в макруху явную проверку диапазона
если писать все такими макросами, чем это будет отличаться от бейсика??? кому вообще такое надо?

Lethargeek

07.01.2011, 08:23

ничего такого в ассемблере НЕТ
Курим доки (вот хотя бы на SJasm) :v2_dizzy_facepalm:

а я и в спектрумовском бейсике могу сделать РЕКУРСИЮ, это не значит что он поддерживает рекурсии.
Он локальных переменных-то не поддерживает :v2_laugh:

приведите-ка пример без poke и usr, убивающий все безвозвратно?
LET a=5:CLOSE #a :v2_tong2:

нет не то же самое. присваивая что-то переменной А, В никогда не попортишь. а в ассемблере не тока В испортишь легко, а еще и сам код!
Ну давай, попорть что-нибудь, обращаясь к A или B по имени :v2_devil:

A: dw $0
B: dw $0

...и потом, там речь совсем не об этом (а о том, что ошибочный результат вычислений точно так же может проявиться не сразу)

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

кому вообще такое надо?
Начинающим - им пока не нужно выжимать из уродца :speccy: максимум :v2_dizzy_roll:
Или при отладке - кому угодно

Vitamin

07.01.2011, 13:26

Что-то уже холиваром попахивает.

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

psb

07.01.2011, 13:55

Он локальных переменных-то не поддерживает
правильно, точно так же как и в асме нет ни структур, ни чего-то еще. это НАДСТРОЙКА, как макрос. а надстройку я сделаю в бейсике и у меня будет работать рекурсия. через жопу, но будет! рекурсия! самая настоящая! от этого бейсик не станет поддерживать рекурсии:)

LET a=5:CLOSE #a
шайтанама!
хорошо, можно к тому условию добавить неиспользование потоков:) где оно такое реально надо? у нас это не используется, а если используется, то это уже выходит за рамки обычного бейсика.

A: dw $0 B: dw $0
лучше так:
A: db $0
B: db $0
байты же у нас не запрещены? и опа: ld (A),hl...
и даже с тем примером, загрузив адрес А в hl, потом случайно изменив hl, попортишь память.

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

Уровнем абстракции и все так же скоростью
т.е. ты пишешь уже как бы не на языке нормального обычного ассемблера, а на каком-то новом, известном только тебе, диалекте птичьего языка:) так тогда не парь моск, пиши на си (http://www.youtube.com/watch?v=XHosLhPEN3k)!

Начинающим - им пока не нужно выжимать из уродца максимум
думаю начинающим важно быстрее понять и научиться добиваться результата. ты же предлагаешь вместо простого понятного почти человеческого языка (basic) выучить ассемблер, как работает проц, какие точки входа есть в пзу, выучить макроязык... не слишком ли? синдром линуксоида налицо :)))

Spectramine

07.01.2011, 14:55

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

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

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

Я имел ввиду не строгое следование канонам структурного программирования, а естественную неоходимость разбиения программы на асме на более-менее автономно написываемые и отлаживаемые блоки. Человеческий разум имеет ограничение на объём одновременно отслеживаемых объектов, именно это естественно заставляет структурировать программы на асме. Конечно, хакерские трюки ассемблер позволяет как никакой другой язык, но на одних трюках более-менее сложную программу не напишешь. Злоупотребление переходами и трюками на асме моментально выливается в очень тяжело отлаживаемые участки кода, что также приводит к осознанию необходимости писать проще.

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

Barmaley_m

07.01.2011, 16:15

лучше так:
A: db $0
B: db $0
байты же у нас не запрещены? и опа: ld (A),hl...
и даже с тем примером, загрузив адрес А в hl, потом случайно изменив hl, попортишь память.
Я примерно то же самое хотел сказать. В ассемблере постоянно возникает необходимость пользоваться косвенной адресацией, то есть указателями. А где указатели - там и их неправильные значения, выход за пределы диапазона, перепахивание памяти. Ставить везде макросы и проверки надо вручную. Для этого новичок в ассемблере должен как минимум озаботиться проблемой постоянных проверок времени выполнения. В бейсике все проверки происходят автоматически, и начинающему программисту не надо об этом беспокоиться.

Ассемблер сам по себе ничего не может, даже такой простой вещи, как вывести сообщение на экран. Все это надо делать через вызов подпрограмм из библиотек. То есть с самого начала надо понять, что такое подпрограммы и с чем их едят. При изучении же бейсика подпрограммы проходятся далеко не на начальном этапе. Первые программы новичков обычно настолько просты, что не содержат операторов GOSUB и RETURN. Встроенные средства бейсика позволяют и без подпрограмм добиться интересных результатов (текст, графика, ввод-вывод). Всего этого достаточно даже чтобы написать простую игру.

То же касается, между прочим, изучения паскаля и других языков высокого уровня при первоначальном знакомстве с программированием. Вызов процедур/функций проходится далеко не на начальном этапе.

ты же предлагаешь вместо простого понятного почти человеческого языка (basic) выучить ассемблер, как работает проц, какие точки входа есть в пзу, выучить макроязык... не слишком ли? синдром линуксоида налицо :)))
Угу, это точно. Тут можно еще добавить изучение библиотек (арифметика, графика, ввод/вывод). То, что библиотеки существуют, еще не значит, что их не надо изучать.

---------- Post added at 16:01 ---------- Previous post was at 15:49 ----------

Человеческий разум имеет ограничение на объём одновременно отслеживаемых объектов, именно это естественно заставляет структурировать программы на асме.
Это ты и я понимаем, что когда разум уже не справляется с указанным отслеживанием - то нужно структурировать программу. То есть мы знаем прием борьбы с этими сложностями. Но новичок-то еще не знает, с чем он столкнулся и как это побороть. Пока он сам дойдет до необходимости структурирования программ, пока выработает свой стиль их структурирования - много воды утечет. На бейсике к тому времени будут достигнуты какие-то результаты, подкрепляющие энтузиазм. А с ассемблером результатов будет меньше, а фрустрации - больше.

На бейсике можно писать программу прямо за компом, без предварительного обдумывания. На ассемблере так можно написать максимум небольшую шаблонную процедуру.
Ну, скажем, опытные зубры среди присутствующих здесь могут и довольно сложные программы на асме с ходу писать :) Но в целом тенденция верная.

Я вот еще на что хочу обратить внимание. Всякие редакторы к играм, которыми пользуются разработчики. Это программы, которые предназначены для того, чтобы единожды их использовать и забыть. Скорость в них не важна, важен только результат (уровни). Взять хотя бы Монти-редактор или редактор уровней Sea Dragon. Разработчик, опытный программист на ассемблере, предпочел написать эти редакторы на бейсике. Догадайтесь, почему :)

---------- Post added at 16:15 ---------- Previous post was at 16:01 ----------

"Студентов, ранее изучавших Бейсик, практически невозможно обучить хорошему программированию. Как потенциальные программисты они подверглись необратимой умственной деградации" (c) Э.Дейкстра
Эта цитата относится к обучению структурному программированию, концепции которого разработал и проповедовал Дейкстра. Именно такое программирование в данном контексте называется "хорошим". Одним из условий этой "хорошести" является отказ от инструкции GOTO. С этой точки зрения ассемблер даже хуже бейсика, потому что там постоянно приходится пользоваться аналогами GOTO, да и остальные средства структурирования программ, такие как локальные переменные, циклы и четко выделенные подпрограммы, отсутствуют.

Если уж следовать заветам великого Дейкстры, то можно начать с обучения программированию на Turbo Pascal под CP/M. Но тогда не будет графики. В бейсике есть графика, и она одна из фактороы, которые очень подогревают энтузиазм начинающих. Ну и средств отладки, изучения состояния программы при останове тоже нет, ведь турбо паскаль - это компилятор.

Lethargeek

08.01.2011, 06:41

правильно, точно так же как и в асме нет ни структур, ни чего-то еще. это НАДСТРОЙКА
Носом ткнуть? Это в голом машинном коде ничего нету. В асмах - ЕСТЬ.
Или я скажу, что в голом бейсике нету никаких команд для работы с графикой
Это все машинно-специфичные НАДСТРОЙКИ, ога

шайтанама!
Это я к тому, что воспетый Бармалеем интерпретатор - это черный ящик
Со своими странностями и глюками, не всегда известными даже человеку опытному

лучше так:
A: db $0
B: db $0
байты же у нас не запрещены?
Запрещены! В синклер-бейсике запрещены же любые числа, кроме пятибайтных :D

и опа: ld (A),hl...
и даже с тем примером, загрузив адрес А в hl, потом случайно изменив hl, попортишь память.
И опа: это уже НЕ "обращение по имени к именованной переменной"
А совсем даже обращение по ссылке (которых в бейсике НЕТУ) :v2_tong2:

а вот когда реально портачатся и данные и код от недосмотра - это всегда пожалуйста, не редкость вообще
Нуичо? Ловится элементарно в том же анрыле остановкой по условию
А вот в бейсике как ты собираешься выяснять, когда именно в переменную попало недопустимое значение?

т.е. ты пишешь уже как бы не на языке нормального обычного ассемблера, а на каком-то новом, известном только тебе, диалекте птичьего языка
Я пишу как мне удобно, а не как захотел сто лет назад аффтар синклер-бейсика
Макросредства и условное ассемблирование уж давным-давно неотъемлемая часть любого асма
Это древние ассемблеры без оных - мертвые диалекты

думаю начинающим важно быстрее понять и научиться добиваться результата.
Вот и пусть начнут с мелких процедур навроде печати символа

ты же предлагаешь вместо простого понятного почти человеческого языка (basic) выучить ассемблер, как работает проц, какие точки входа есть в пзу, выучить макроязык... не слишком ли? синдром линуксоида налицо
Это ты мне, старому закоренелому вендузятнику? :v2_lol:
К слову, я вообще никогда ничего не учу заранее
Лазаю в учебники и справочники по ходу дела

---------- Post added at 06:41 ---------- Previous post was at 05:14 ----------

Я примерно то же самое хотел сказать. В ассемблере постоянно возникает необходимость пользоваться косвенной адресацией, то есть указателями
НЕТ такой НЕОБХОДИМОСТИ :v2_dizzy_facepalm:
Ни редко, ни постоянно

Ставить везде макросы и проверки надо вручную. Для этого новичок в ассемблере должен как минимум озаботиться проблемой постоянных проверок времени выполнения.
Лоллллл, каких еще "проверок времени выполнения"?
Чтоб у начинающего бордюрные эффекты не съехали? :D

Начинающий вполне может поначалу работать в стиле:

A: dw 12
B: dw 34
C: dw 0

...

CravnoAplusB:
ld hl,(A)
ld de,(B)
add hl,de
ld (C),hl

...все равно получится многократно быстрее бейсика

Ассемблер сам по себе ничего не может, даже такой простой вещи, как вывести сообщение на экран. Все это надо делать через вызов подпрограмм из библиотек.
Чушь! просто нужно начинать с еще более простых вещей
Например, с вывода на экран не сообщения, а всего лишь байта
Потом символа, а потом процедура вывода сообщения сама получится

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

В том же Лого, специально разработанном для обучения маленьких детей :D
к процедурам переходят сразу же после освоения команд управления черепашкой
то есть фактически - для начала на уровне простейшего макроса

Угу, это точно. Тут можно еще добавить изучение библиотек (арифметика, графика, ввод/вывод). То, что библиотеки существуют, еще не значит, что их не надо изучать.
...или что изучать их надо непременно целиком и сразу :rolleyes:
Можно хоть на форуме спросить, если что неясно

Это ты и я понимаем, что когда разум уже не справляется с указанным отслеживанием - то нужно структурировать программу. То есть мы знаем прием борьбы с этими сложностями. Но новичок-то еще не знает, с чем он столкнулся и как это побороть. Пока он сам дойдет до необходимости структурирования программ, пока выработает свой стиль их структурирования - много воды утечет. На бейсике к тому времени будут достигнуты какие-то результаты, подкрепляющие энтузиазм. А с ассемблером результатов будет меньше, а фрустрации - больше.
Нужно просто перестать постоянно видеть трудности там, где их нет
Начиная с мелочей в ассемблере, набираешь опыт постепенно
Начиная с бейсика, пропускаешь важнейший пласт в начале

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

вот еще на что хочу обратить внимание. Всякие редакторы к играм, которыми пользуются разработчики. Это программы, которые предназначены для того, чтобы единожды их использовать и забыть. Скорость в них не важна, важен только результат (уровни). Взять хотя бы
...взять хотя бы песюковый офис, чтобы не мучиться :p

Эта цитата относится к обучению структурному программированию, концепции которого разработал и проповедовал Дейкстра. Именно такое программирование в данном контексте называется "хорошим". Одним из условий этой "хорошести" является отказ от инструкции GOTO.
Отказ только от "неструктурного" GOTO, а не вообще

С этой точки зрения ассемблер даже хуже бейсика, потому что там постоянно приходится пользоваться аналогами GOTO, да и остальные средства структурирования программ, такие как локальные переменные, циклы и четко выделенные подпрограммы, отсутствуют.
В голове они у тебя отсутствуют, а не в современных ассемблерах :v2_dizzy_facepalm:

Если уж следовать заветам великого Дейкстры, то можно начать с обучения программированию на Turbo Pascal под CP/M
А при чем тут СПЕКТРУМ? :v2_conf2:

В бейсике есть графика, и она одна из фактороы, которые очень подогревают энтузиазм начинающих. Ну и средств отладки, изучения состояния программы при останове тоже нет
И в бейсике нет (по сравнению с дебагером в анрыле это же бугагашечки)
Говорил же, на Спеке начните с Лого - там и графика, и редактор лучше
И любую процедуру можно вызывать по имени с командной строки

psb

08.01.2011, 10:12

Lethargeek, ты неодекват:)

1. мы говорим не о тебе таком крутом, а о новичках
2. ты напроч забыл, каким ты был, когда 1й раз увидел компьютер
3. ты, наверное, не общаешься с такими начинающими, поэтому тебе ни в жизнь не понять их психологию, посему, я бы сказал, что ты не имеешь права что-то им советовать:) в любом случае - это только на твоей совести, и не повезет тому, кто будет у тебя учиться:)

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

остальной бред даже комментировать не хочется...

Lethargeek

08.01.2011, 12:37

1. мы говорим не о тебе таком крутом, а о новичках
Кто крутой, я крутой? Да я даже... хм, ну ладно. Хорошо, допустим, что я крутой. Но тогда пред нами с трагической неизбежостью возникает из вековых глубин закономерный вопрос: КАК я смог добиться столь невероятной, столь нечеловеческой крутизны? ;)

2. ты напроч забыл, каким ты был, когда 1й раз увидел компьютер
Я прекрасно помню, как в "первый раз" увидел... программируемый калькулятор!
Начинал с него же, как очень многие. И ничо, не помер. Многому научился.
А как раз на синклер-бейсик потом только время потратил зря.

ты, наверное, не общаешься с такими начинающими, поэтому тебе ни в жизнь не понять их психологию, посему, я бы сказал, что ты не имеешь права что-то им советовать
Ололо, да ты сам-то линухоеда от вендузятника не отличаешь, что ты можешь посоветовать и кому? :v2_laugh:

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

остальной бред даже комментировать не хочется...
Слиф защитан :v2_tong2:

psb

08.01.2011, 13:24

КАК я смог добиться столь невероятной, столь нечеловеческой крутизны?
вопрос не в этом, а в том что УЖЕ добился, и рассуждаешь с этой т.з.

Я прекрасно помню, как в "первый раз" увидел... программируемый калькулятор!
Начинал с него же, как очень многие.
за многих я бы не стал.
rst7 в одном из интервью сказал, что на спек он пришел подготовленным, имеющий опыт прогания на других платформах. не зная этого мы можем долго удивляться, как так человек в начале 90х (а именно в это время спеки стали массово появляться у всех) вдруг стал круто кодить? почему он так быстро научился, а остальные только-только подтягивались? ответ-то прост - он УЖЕ умел.
и ты так же, ты УЖЕ умел, потому для тебя бейсик был пустой тратой, а в целом ты был уже не такой новичок. я не считаю в своем опыте бейсик пустой тратой времени, абсолютно. всему должно быть свое место в обучении.

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

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

Слиф защитан
да нет, просто времени жалко комментировать реально бред. но ты-то считай как считаешь:)

Barmaley_m

08.01.2011, 14:28

Это я к тому, что воспетый Бармалеем интерпретатор - это черный ящик
Со своими странностями и глюками, не всегда известными даже человеку опытному
Это притянутый за уши аргумент. Нашел единственный баг в бейсике, который проявляется в экзотической ситуации - и раздул из него слона. Все известные баги синклер-бейсика достаточно редко проявляются, чтобы начинающие от этого не страдали.

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

Запрещены! В синклер-бейсике запрещены же любые числа, кроме пятибайтных :D
Странный выкрик, не относящийся к делу.

И опа: это уже НЕ "обращение по имени к именованной переменной"
А совсем даже обращение по ссылке (которых в бейсике НЕТУ) :v2_tong2:
Да, в бейсике этого нету, и слава Богу, иначе отладка программ на бейсике была бы столь же трудной, как на ассемблере. Большинство задач, которые решаются на бейсике, спокойно решаются и без косвенной адресации. В ассемблере же косвенная адресация нужна постоянно и везде. Об этом ниже.

Макросредства и условное ассемблирование уж давным-давно неотъемлемая часть любого асма
Это древние ассемблеры без оных - мертвые диалекты
Уже сто раз говорили, что первые шаги на ассемблере делаются без макросредств и условного ассемблирования, потому что изучить сразу все немыслимо для человеческого мозга.

Вот и пусть начнут с мелких процедур навроде печати символа
Ничего себе "мелких". Печать символа - это нетривиальная задача. Думаю без преувеличения, что начинающий может потратить месяц на ее решение - при условии упорства и настойчивости. А в результате - один напечатанный символ. Да с таким темпом успехов ни один даже самый волевой человек не станет изучать программирование дальше!

А там, глядишь, освоит и печать числа на экран. Сможет прибавить 5 + 5 и напечатать результат на экран в десятичной системе. Ну-ну. В каком классе школы проходят системы счисления? А ведь мне было, например, 12 лет, когда я начал изучать программирование. Задолго до того как.

К слову, я вообще никогда ничего не учу заранее
Лазаю в учебники и справочники по ходу дела
Это когда основные принципы тебе понятны. А когда ты совсем зеленый новичок, такой подход не работает. Попробуй, например, научиться доить корову таким способом - по ходу дела.

НЕТ такой НЕОБХОДИМОСТИ
Ни редко, ни постоянно
Да ну? ;) Попробуй написать всю ту же пресловутую процедуру печати на экран сообщения без использования косвенной адресации.

Лоллллл, каких еще "проверок времени выполнения"?
По-английски это называется Run-time check. Проверок на предмет выхода за пределы диапазона, недопустимых значений аргумента функции, ошибки при выполнении функции и т.д.

Начинающий вполне может поначалу работать в стиле:

CravnoAplusB:
ld hl,(A)
ld de,(B)
add hl,de
ld (C),hl

Чего можно добиться такими программами? Сложения чисел, которые лежат в памяти, непонятно как туда попали, и непонятно как посмотреть результат? Ведь видимых (на экране) действий компьютер от таких программ не выполнит. Знаешь почему лично меня программирование увлекло когда мне было 12 лет? Потому что можно быстро добиться ощутимого по масштабам результата.

...все равно получится многократно быстрее бейсика
Да это просто смешно! Для отдельно взятого сложения двух чисел скорость не играет никакой роли!

Чушь! просто нужно начинать с еще более простых вещей
Например, с вывода на экран не сообщения, а всего лишь байта
Ну-ну. И через сколько времени мы доберемся до того, как человек сможет написать простую текстовую игру? И сколько ненужной (для достижения этого результата) информации ему при этом придется освоить? Начинающему на бейсике нет необходимости вообще понимать, что такое экранная область и на каком принципе на ней отображаются символы.

Личный опыт оставь на совести своих препов
Про "другие языки" и "начальное знакомство" тоже не спеши с выводами
С какой это стати? Есть возражения? Приведи.

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

...или что изучать их надо непременно целиком и сразу :rolleyes:
Можно хоть на форуме спросить, если что неясно
Изучать библиотеки для арифметики и вывода на экран заведомо сложнее, чем изучить оператор PRINT a+b*COS(c). И задавание на форуме вопросов этот факт не изменит.

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

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

Начиная с бейсика, пропускаешь важнейший пласт в начале
Что же это за "важнейший пласт" и почему его нельзя изучить потом?

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

Дык она еще на синклер-бейсике чем длиннее, тем тормознее
У начинающих длинных программ не бывает. А тот, кто смог написать длинную программу, чтобы она не глючила, но неприемлемо тормозила из-за недостатков бейсика - уже созрел для изучения ассемблера.

...взять хотя бы песюковый офис, чтобы не мучиться :p
Реплика, не относящаяся к делу.

Отказ только от "неструктурного" GOTO, а не вообще
Это тоже не относится к делу. Фраза Дейкстры касалась структурного программирования, а ассемблер не является структурным языком, в отличие от паскаля, например. Поэтому в контексте той фразы Дейкстры студенты, изучавшие ранее ассемблер вместо бейсика, были подвержены такому же разлагающему влиянию свободы GOTO и других факторов.

В голове они у тебя отсутствуют, а не в современных ассемблерах
Указанные вещи отсутствуют в любых ассемблерах Z80, потому что процессор не поддерживает таких концепций. Ассемблеры поддерживают эти вещи за счет директив, которые надо изучать, и ограничений на стиль программирования, которые тоже надо изучать.

А при чем тут СПЕКТРУМ?
CP/M можно запускать на некоторых Спектрумах. Например, у ASC был фирменный Spectrum +2, на котором работала CP/M. Но турбо паскаль - это единственный пригодный к употреблению паскаль, который я когда-либо видел на спектрум-совместимых компьютерах. Потому я его и упомянул. Есть еще hisoft pascal, но это по-моему издевательство, а не среда программирования.

Между прочим, именно на паскале в CP/M я первоначально отрабатывал некоторые сложные алгоритмы, например бота для игры в морской бой. Только после отладки переводил его на ассемблер.

И в бейсике нет (по сравнению с дебагером в анрыле это же бугагашечки)
Никакие не бугагашечки. Ты очень недооцениваешь возможность исполнения команд языка во время останова, возможность вычисления выражений, распечатки на экран значений переменных в "человеческом" виде, а также внесения изменений в отлаживаемую программу БЕЗ необходимости ее перекомпиляции и перезапуска с нуля.

Не знаю, приходилось ли тебе отлаживать на ассемблере действительно сложный алгоритм, наподобие численных методов. Мы можем просто говорить на разных языках.

Lethargeek

08.01.2011, 14:31

вопрос не в этом, а в том что УЖЕ добился
ОТВЕТ в том, что я знаю КАК :v2_tong2:

за многих я бы не стал.
Что ты говоришь :D ну еще скажи: ПМК был ужасной редкостью в советские времена :v2_laugh:

ответ-то прост - он УЖЕ умел. и ты так же, ты УЖЕ умел
Умел ЧТО? Программировать В КОДАХ калькулятора. ИЧСХ научился быстро.
Если б начал с эмулированного Z80, было б еще быстрее - эмуль же удобнее на порядок!
Следовательно: СЕЙЧАС бейсик начинающему НЕ НУЖЕН :D

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

проблемы-то их, но это показатель! я очень много сталкиваюсь с ассемблером, и вижу много людей, работающих с ним, вижу как они работают. имея какой-то опыт, понимая как и что, все равно они работают с ним неуклюже. ты может быть крут, умело используешь разные приемы, а остальные пусть будут ТУПАРИ
Да ты что, я туплю со страшной силой в простых задачах...
Просто с эмулятором и другими ништяками можно позволять себе быть тупее

просто свыкнись с этой мыслью, что не все гении, и поймешь, что ты не прав в том, что ассемблер так легок.
Свыкнись с мыслью, что ассемблер с эмулятором проще бейсика :p

psb

08.01.2011, 14:51

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

---------- Post added at 16:51 ---------- Previous post was at 16:40 ----------

ну еще скажи: ПМК был ужасной редкостью в советские времена
никогда его не видел и не видел того, кто его видел.

Умел ЧТО? Программировать В КОДАХ калькулятора.
ты вообще понимал хотя бы, что такое программирование. надо даже не уметь программировать на каком-то языке, а представлять как составляются алгоритмы. блин, я прекрасно помню период, когда я знал все операторы бейсика, я бы тебе нарисовал что хочешь, напечатал что хочешь, посчитал... но я не представлял как можно сделать игру, где одновременно двигаются враги и двигаешься ты. понимаешь, это трудно понять вот так просто. но нифига ж ты не понимаешь:)

синдром линуксоида
синдром линуксоида не означает что у тебя линукс или ты линуксоид.

Да ты что, я туплю со страшной силой в простых задачах...
что мы тут и видим:)))))

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

Свыкнись с мыслью, что ассемблер с эмулятором проще бейсика
с чего? пока что ты не привел ни фактов, ни каких-либо вменяемых доводов. все голословно. ты говоришь "поверь", а я не поверю с высоты своего опыта!

собственно, тебе не странно, что тебя убеждают гуру ассемблера Z80, что он сложнее бейсика? ладно бы ламеры жаловались на сложность... в этом, кстати, синдром и состоит.

Barmaley_m

08.01.2011, 16:22

Ладно, psb, давай не будем спорить. Lethargeek иногда заносит, я это видел и в других темах. Он просто никогда не отступает от своей позиции, даже если ошибается. Есть люди с такими принципами. Думаю, что любой человек, которому не чуждо логическое мышление, из этого обсуждения все, что надо, усвоил.

John North

08.01.2011, 16:46

Пару слов в защиту басика.
Он тем и хорош, что сразу же чувствуешь отдачу, то есть сразу видишь результат своих действий. Что для новичка является очень хорошим стимулом.
А программирование вообще - это НЕ знание всех команд языка, а как и сказал psb, надо уметь понимать задачу.

Vitamin

08.01.2011, 21:15

Ой, а кто мне расскажет, как на бейсике (спектрумовском естесно) написать и вызвать процедуру? А как вернуть из нее значение? А как вернуть несколько значений?

Ответ "используй глобальные переменные" автоматически означает быдлокодера (вот такой вот я злой).

Barmaley_m

08.01.2011, 23:48

Ответ "используй глобальные переменные" автоматически означает быдлокодера (вот такой вот я злой).
Следует ли понимать это высказывание как аргумент в пользу простоты ассемблера по сравнению с бейсиком?

Как же тогда небыдлокодеры передают в процедуры переменные и возвращают из нее значения на ассемблере, если не секрет?

moroz1999

08.01.2011, 23:53

Как минимум есть директивы MODULE/ENDMODULE, определяющие область видимости меток.

Lethargeek

09.01.2011, 00:10

Это притянутый за уши аргумент. Нашел единственный баг в бейсике, который проявляется в экзотической ситуации - и раздул из него слона. Все известные баги синклер-бейсика достаточно редко проявляются, чтобы начинающие от этого не страдали.
Ну-ну-ну. Взять хотя бы "1/2<>0.5" - неизменно превосходный результат!

Бейсик - проверенный временем, прошедший огонь, воду и медные трубы инструмент программирования на Спектруме.
Время подтвердило только полную НЕпригодность бейсика для игрушек
Сколько даже не хороших, а хотя бы сносных игр для Спека на бейсике?
Тех, с которыми не хочется через две минуты нажать на резет?

Если на то пошло, то "современные ассемблеры" с их навороченными макро- и прочими средствами - тоже по сути черные ящики со своими странностями и глюками.
Чушь. У ассемблера на выходе - чистый код (можно по шагам отслеживать в эмуляторе) и листинг (можно вешать рядом с эмулятором для проверок). Если даже глюки будут, увидишь сразу.

Да, в бейсике этого нету, и слава Богу, иначе отладка программ на бейсике была бы столь же трудной, как на ассемблере. Большинство задач, которые решаются на бейсике, спокойно решаются и без косвенной адресации. В ассемблере же косвенная адресация нужна постоянно и везде. Об этом ниже.
Большинство задач в ассемблере спокойно решаются без косвенной адресации к переменным.
Да, не самым эффективным способом, но РЕШАЮТСЯ. Начинающему достаточно.
Следовательно - косвенная адресация НЕ нужна "постоянно и везде"
Уж во всяком случае не больше, чем в том же бейсике (об этом ниже)

Уже сто раз говорили, что первые шаги на ассемблере делаются без макросредств и условного ассемблирования, потому что изучить сразу все немыслимо для человеческого мозга.
А вторые - с макросредствами по мере их изучения. В ЧЕМ ПРОБЛЕМА?

Ничего себе "мелких". Печать символа - это нетривиальная задача. Думаю без преувеличения, что начинающий может потратить месяц на ее решение - при условии упорства и настойчивости. А в результате - один напечатанный символ. Да с таким темпом успехов ни один даже самый волевой человек не станет изучать программирование дальше!
Контрпример - Lethargeek, человек чудовищно ленивый, вялый, сонный и слабовольный :p
Провозился пару часов (потому что набирал машинный код ручками во встроенном мониторе)
Адреса в дисплейном файле обнаружил методом тыка (мануалов не было)

Это когда основные принципы тебе понятны. А когда ты совсем зеленый новичок, такой подход не работает.
С калькулятором же сработало

Попробуй написать всю ту же пресловутую процедуру печати на экран сообщения без использования косвенной адресации.
Разговор вообще-то шел о косвенных обращениях к переменным
Или я скажу, что в бейсике тоже "постоянно требуется косвенная адресация"
Например, даже в случае простейшего "PRINT AT VarX, VarY;VarChar$"
Ажно целых три косвенных параметра :D

По-английски это называется Run-time check
А по-русски - "проверки ПРИ выполнении"

Чего можно добиться такими программами? Сложения чисел, которые лежат в памяти, непонятно как туда попали, и непонятно как посмотреть результат? Ведь видимых (на экране) действий компьютер от таких программ не выполнит.
Непонятно? А немного поднапрячь ну-совсем-непострадавшие-от-бейсика-мозги и слегка подумать?
У тебя же под рукой эмулятор! В котором можно видеть и редактировать что угодно, когда угодно, и где угодно!

Да это просто смешно! Для отдельно взятого сложения двух чисел скорость не играет никакой роли!
Не придуривайся. Сразу станет несмешно, когда то же самое сложение будет в цикле.

Ну-ну. И через сколько времени мы доберемся до того, как человек сможет написать простую текстовую игру? И сколько ненужной (для достижения этого результата) информации ему при этом придется освоить?
А у человека цель напейсать какашку и успокоиться? Все, тогда сдаюсь - *****бейсик в руки :D
Или все же хочется, чтобы не было потом мучительно больно за бесцельно нажатые кнопки?

С какой это стати? Есть возражения? Приведи.
Разуй глаза

Что-то я не слышал,
Вынь бананы из ушей

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

Изучать библиотеки для арифметики и вывода на экран заведомо сложнее, чем изучить оператор PRINT a+b*COS(c). И задавание на форуме вопросов этот факт не изменит.
Изучать библиотеки или кодить собственные процедуры, если цель писать игрушки - полезно
Изучать "PRINT a+b*COS(c)" - БЕСПОЛЕЗНО

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

А трудности есть, потому что программа на ассемблере даже для простейших действий, вроде вывода на экран сообщений, уже становится настолько большой, что требует специальных приемов, облегчающих ее понимание человеку.
Что за страшные приемы так важны для понимания короткой строчки "CALL PRINT"? :v2_dizzy_facepalm:

Что же это за "важнейший пласт"
Выработка чувства достаточности

и почему его нельзя изучить потом?
Можно. Но, во-первых, время потратил зря, во-вторых - сформированы вредные привычки

У начинающих длинных программ не бывает.
А короткие никому на GUI не упали

А тот, кто смог написать длинную программу, чтобы она не глючила, но неприемлемо тормозила из-за недостатков бейсика
...тот время потратил зря. Потому что в асме он снова начинающий :D

Реплика, не относящаяся к делу.
Твоя? Да. И уже далеко не первая.

Это тоже не относится к делу. Фраза Дейкстры касалась структурного программирования, а ассемблер не является структурным языком, в отличие от паскаля, например. Поэтому в контексте той фразы Дейкстры студенты, изучавшие ранее ассемблер вместо бейсика, были подвержены такому же разлагающему влиянию свободы GOTO и других факторов.
Современный макроассемблер является чем захочешь
И в паскале GOTO жив и здоров

Указанные вещи отсутствуют в любых ассемблерах Z80, потому что процессор не поддерживает таких концепций. Ассемблеры поддерживают эти вещи
Ты бы определился - так "отсутствуют" или все-таки "поддерживает" :v2_laugh:

CP/M можно запускать на некоторых Спектрумах. Например, у ASC был фирменный Spectrum +2, на котором работала CP/M
Разве что +3, только в них можно отображать ОЗУ в 0-16К (то есть полностью похерить совместимость с обычным Спеком)

Между прочим, именно на паскале в CP/M я первоначально отрабатывал некоторые сложные алгоритмы, например бота для игры в морской бой. Только после отладки переводил его на ассемблер.
Между прочим, на дворе 2011 год, на столе песюк!

Никакие не бугагашечки. Ты очень недооцениваешь возможность исполнения команд языка во время останова, возможность вычисления выражений, распечатки на экран значений переменных в "человеческом" виде, а также внесения изменений в отлаживаемую программу БЕЗ необходимости ее перекомпиляции и перезапуска с нуля.
Это ты не понимаешь, ЗАЧЕМ это БЫЛО нужно и ПОЧЕМУ

Не знаю, приходилось ли тебе отлаживать на ассемблере действительно сложный алгоритм, наподобие численных методов. Мы можем просто говорить на разных языках.

Отлаживать на бейсике сложные алгоритмы проще, чем на ассемблере, и если ты этого не понимаешь, то попробуй сделать и отладить на ассемблере, к примеру, процедуру аппроксимации методом наименьших квадратов. Сообщишь мне, сколько это заняло времени.
Аттеншен! Ду ю рид ми? Але, гараж? Кто нибудь здесь спрашивал про "сложные численные алгоритмы"?
Если кто не в курсе, были заданы вопросы "Подскажите пожалуйста, На каких языках пишутся игры"
и "С чего нужно начинать, что-бы написать примитивную игру с простой черно-белой графикой?"
А теперь поведай мне, нахрена в простых игрушках регрессионный анализ?

---------- Post added at 00:10 ---------- Previous post was at 00:06 ----------

А программирование вообще - это НЕ знание всех команд языка, а как и сказал psb, надо уметь понимать задачу
Эти "пониматели" хоть бы заголовок прочли сначала :rolleyes:

Vitamin

09.01.2011, 00:18

Следует ли понимать это высказывание как аргумент в пользу простоты ассемблера по сравнению с бейсиком?
Совсем нет. Это следует понимать как аргумент в пользу как можно более раннего ухода с бейсика, желательно "закончить, не начав". Я не раз видел результат применения "бейсикового" подхода к программированию на других языках- одна огромная стартовая функция и миллиард глобальных переменных. Хотя во всех учебниках того же паскаля функции и процедуры изучаются буквально в первых главах.

Как же тогда небыдлокодеры передают в процедуры переменные и возвращают из нее значения на ассемблере, если не секрет?
Неужели неизвестно?
1) Через стек
2) Передавая указатель на эти переменные. Где они физически расположены (в куче, в стеке, глобально) - не важно.

Lethargeek

09.01.2011, 00:31

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

---------- Post added at 00:39 ---------- Previous post was at 00:27 ----------

кстати, я вспомнил еще один факт. когда я начинал изучать ассемблер, я писал программки на нем и проверял их на скорость. типа вывода строк, рисования линий и т.п. так вот, работало оно не на много быстрее бейсика!!!
Ты бы лучше вспомнил, что "процедуры типа рисования линий" в ПЗУ довольно длинные
Разницу заметишь, если будешь в цикле рисовать множество коротких отрезков

никогда его не видел и не видел того, кто его видел
Тематические разделы в общесоюзных журналах с миллионными тиражами тоже никогда не видел?

ты вообще понимал хотя бы, что такое программирование.
Угу. После калькулятора, который как-то же сумел освоить БЕЗ "понимания"

блин, я прекрасно помню период, когда я знал все операторы бейсика, я бы тебе нарисовал что хочешь, напечатал что хочешь, посчитал... но я не представлял как можно сделать игру, где одновременно двигаются враги и двигаешься ты
Потому-то я и говорю: бейсик вреден :D

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

что мы тут и видим
Вам сюда: http://zx.pk.ru/showthread.php?t=14677

с этим я согласен, но это не отрицает факта сложности ассемблера
Где-то приводились доказательства его сложности? :rolleyes:

с чего? пока что ты не привел ни фактов, ни каких-либо вменяемых доводов. все голословно. ты говоришь "поверь", а я не поверю с высоты своего опыта!
Это вы здесь гоните, что в ассемблерах нет того-сего-другого-третьего
Или притворяетесь, будто наступил 1984, а не 2011

собственно, тебе не странно, что тебя убеждают гуру ассемблера Z80, что он сложнее бейсика?
Кто вас только выпустил из гурятника...

psb

09.01.2011, 00:57

Это следует понимать как аргумент в пользу как можно более раннего ухода с бейсика, желательно "закончить, не начав".
а ухода куда? на асм что ли??
если уход на си/паскаль, то это совсем другое дело, а сразу на асм - бред.

Где они физически расположены (в куче, в стеке, глобально) - не важно.
т.е. нормально, если все переменные физически будут глобальные?:) будем на бейсике тогда переменные обзывать modulename_varname, и будем думать, что у нас существуют области видимости:)

Ой, а кто мне расскажет, как на бейсике (спектрумовском естесно) написать и вызвать процедуру? А как вернуть из нее значение? А как вернуть несколько значений?
можно не использовть глобальные переменные, можно сделать массив и заэмулить на нем стек. возвращать в результат в одной глобальной переменной. а что? именно так и работает в асме.

---------- Post added at 02:57 ---------- Previous post was at 02:42 ----------

Ты бы лучше вспомнил, что "процедуры типа рисования линий" в ПЗУ довольно длинные
Разницу заметишь, если будешь в цикле рисовать множество коротких отрезков
какая к черту разница? факт, много печатаешь или рисуешь - тормоза! плохой твой метод вызывать подпрограммы из пзу. не сделать так игру!

Угу. После калькулятора, который как-то же сумел освоить БЕЗ "понимания"
по себе людей не судят, знаешь такое?

Потому-то я и говорю: бейсик вреден
ппц олень

Ты настолько промахнулся с его диагнозом, что наверняка не распознаешь и линуксоида
ты правда такой тупой? или просто троллишь?

Где-то приводились доказательства его сложности?
еще раз для тех кто в танке:

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

Это вы здесь гоните, что в ассемблерах нет того-сего-другого-третьего
какой смысл говорить что ты пишешь на асме, если ты фигачишь макросами, которые тебе все упрощают? что? ты в дебаггере видишь настоящий асм? так ты и после си и паскаля увидишь настоящий асм! даже бейсик можешь подебажить.
а в нормальном обычном ассемблере никаких структур - нет и не было никогда. пиши на си, компиль и думай что макросами пишешь на асме:)

Кто вас только выпустил из гурятника...
ха-ха, а по делу?

Lethargeek

09.01.2011, 01:55

какая к черту разница? факт, много печатаешь или рисуешь - тормоза! плохой твой метод вызывать подпрограммы из пзу
Что ты гонишь, с какого перепугу он стал "моим"?

по себе людей не судят, знаешь такое?
ПМК успешно освоили миллионы, знаешь такое?

ты правда такой тупой? или просто троллишь?
Ты успешно совмещаешь :v2_clap2:

еще раз для тех кто в танке:
Цитата:
Сообщение от psb
проблемы-то их, но это показатель! я очень много сталкиваюсь с ассемблером, и вижу много людей, работающих с ним, вижу как они работают. имея какой-то опыт, понимая как и что, все равно они работают с ним неуклюже.
А вот нефиг было с бейсика начинать :v2_tong2:
И еще раз для тех, кто в танке: с эмулем неуклюжесть можно себе позволить

я видел это сам лично 100500 раз, и еще предстоит видеть хз сколько, работа такая...
Это не работа, это наказание тебе ниспослано Ктулхой :v2_laugh:

какой смысл говорить что ты пишешь на асме, если ты фигачишь макросами, которые тебе все упрощают?
Мда, тяжелый случай... ПОТОМУ ЧТО ЭТО И ЕСТЬ АССЕМБЛЕР!!
В макросах такой же машинный код, мною же написанный!
Ровно то же самое можно тупо набрать и ручками, но зачем?
Впрочем, судя по

даже бейсик можешь подебажить
или по

можно сделать массив и заэмулить на нем стек
Понимаю: мегагуру легких путей не ищут :v2_laugh:

а в нормальном обычном ассемблере никаких структур - нет и не было никогда. пиши на си, компиль и думай что макросами пишешь на асме
А в нормальном оригинальном бейсике (кстати, компиляторе) не было поначалу инпута :D
И о чем ты думаешь, нагло пользуясь этим сатанинским изобретением?

Vitamin

09.01.2011, 02:07

а ухода куда? на асм что ли??
если уход на си/паскаль, то это совсем другое дело, а сразу на асм - бред.
Да я какбэ если и агитирую за переход на асм, то сугубо в рамках спектрума. Ибо альтернатив нет.
На других платформах- как раз другие языки. Разные для разных целей.

т.е. нормально, если все переменные физически будут глобальные? будем на бейсике тогда переменные обзывать modulename_varname, и будем думать, что у нас существуют области видимости
Переделать глобальную переменную на любую другую- копеешное дело, если все ссылки косвенные. Это к вопросу о мракобесной для тебя области сопровождаемости кода:)

можно не использовть глобальные переменные, можно сделать массив и заэмулить на нем стек. возвращать в результат в одной глобальной переменной. а что? именно так и работает в асме.
Покажи хотя бы одну программу на бейсике, делающую это. А также "начинающего погроммиста", который так будет делать. А ведь упор именно на начинающих делается.

Spectramine

09.01.2011, 02:18

Бейсик вреден, только если человек, освоив бейсик, кроме него больше ничего изучать не хочет. Таким же макаром вреден и ассемблер. И даже паскаль и си.

А что касается лёгкости изучения основ программирования - бейсик рулит по ряду причин. Вкратце - изучать программирование на примере языка бейсик можно: 1) последовательно от простых абстракций к сложным, в процессе пробуя каждую на примерах; 2) в дружественной среде интерпретатора/мгновенного исполнителя; 3) используя достаточно мощные встроенные языковые средства ввода/вывода.

Изучая ассемблер, прежде чем написать хотя бы простенькую программку, придётся сразу освоить целый массив абстракций - процессор, модель памяти, команды, регистры, метки, стек, исходный текст, компиляция, машинный код... Да, человеку, который уже_имеет_ опыт программирования ПМК, ассемблер изучить будет гораздо проще, но и только. Далекий от программирования разум новичка просто не осилит написание даже простейшей программы по обработке чисел на ассемблере. А если и осилит, это ему мало что даст. Один знакомый так и говорил - я вроде все команды понимаю, а как игры пишутся, так и не понял.

Lethargeek

09.01.2011, 02:49

Бейсик вреден, только если человек, освоив бейсик, кроме него больше ничего изучать не хочет. Таким же макаром вреден и ассемблер
А что ст0ит изучить на Спеке после ассемблера? Разве только Форт... чтобы переделать его немедленно :D

изучать программирование на примере языка бейсик можно: 1) последовательно от простых абстракций к сложным, в процессе пробуя каждую на примерах;
Это можно даже в голом машинном коде

2) в дружественной среде интерпретатора/мгновенного исполнителя;
Эмулятор+SJasm+compile.bat

3) используя достаточно мощные встроенные языковые средства ввода/вывода.
Эмулятор: и так все видно

Изучая ассемблер, прежде чем написать хотя бы простенькую программку, придётся сразу освоить целый массив абстракций - процессор, модель памяти, команды, регистры, метки, стек, исходный текст, компиляция, машинный код...
Я свою первую простенькую программку набрал тупо во встроенном мониторе Турбо-90, больше половины команд не зная :D

Да, человеку, который уже_имеет_ опыт программирования ПМК, ассемблер изучить будет гораздо проще, но и только
Проще. Но в итоге будет просто сэкономлено время, ранее потраченное на ПМК

Далекий от программирования разум новичка просто не осилит написание даже простейшей программы по обработке чисел на ассемблере.
Калькулятор для "далекого от программирования разума" ничуть не проще Z80
Даже неудобнее при отладке, все регистры сразу ему не видно
Уйма недокументированных глюков
И ничо, асиливали вполне

Один знакомый так и говорил - я вроде все команды понимаю, а как игры пишутся, так и не понял.
Ассемблер тут ни при чем. Твой знакомый просто не понимает как игры пишутся.

Spectramine

09.01.2011, 04:16

А что ст0ит изучить на Спеке после ассемблера? Разве только Форт... чтобы переделать его немедленно :D Что угодно, на Спеке свет клином не сошёлся.

Это можно даже в голом машинном коде
Нельзя. Как и для ассемблера, чтобы начать программировать в машинном коде, нужно освоить сразу целый ряд новых абстракций. Для бейсика достаточно двух-трёх, основанных на уже известных из реальной жизни.

Эмулятор+SJasm+compile.bat

Изучение 3х или 4х PC-шных программ вместо одного ПЗУ-шного бейсика. К тому же, язык bat-файлов - ещё один язык программирования, который тоже придётся изучать. (И я бы не назвал такую связку "дружественной". Удобной при определённом опыте - и то с трудом. ) Это вообще за гранью понимания предмета спора.

Эмулятор: и так все видно Я имел ввиду не для мониторинга, а для программного ввода/вывода.

Я свою первую простенькую программку набрал тупо во встроенном мониторе Турбо-90, больше половины команд не зная :D
Ай, маладца! :) Особливо с учётом опыта программирования ПМК.

Проще. Но в итоге будет просто сэкономлено время, ранее потраченное на ПМК
Оно будет потрачено на изучение абстракций программирования вообще и машиннокодового в частности. Человек после ПМК знает почти всё, что нужно для изучения ассемблера любого процессора.

Калькулятор для "далекого от программирования разума" ничуть не проще Z80
Даже неудобнее при отладке, все регистры сразу ему не видно
Уйма недокументированных глюков
И ничо, асиливали вполне
То, что отдельные личности, в силу определённого склада ума и течения жизни, сумели первым делом осилить ПМК (не факт, что с полпинка), никак не доказывает, что любому начинающему программировать стоит сразу изучать ассемблер.

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

Barmaley_m

09.01.2011, 04:41

Взять хотя бы "1/2<>0.5" - неизменно превосходный результат!
Ты сам когда-нибудь или кто-то из твоих знакомых натыкался на этот баг? Я - никогда, хотя на бейсике на Спеке в свое время сделал немало. Сравнивать дробные числа на равенство - это плохая практика, от которой нас преподы предостерегали на самых первых лекциях. Так что данный аргумент не может считаться достаточным для отвержения бейсика в качестве инструмента программирования, в том числе игр.

Время подтвердило только полную НЕпригодность бейсика для игрушек
Сколько даже не хороших, а хотя бы сносных игр для Спека на бейсике?
Тех, с которыми не хочется через две минуты нажать на резет?
Вагон и маленькая тележка. Часть из них упоминалась и на этой ветке. Диктатор, президент, хлебное королевство, Титан (Ground force zero). Когда-то я сделал на бейсике сапера - тоже можно было вполне сносно играть по настроению. Даже друзья в гостях играли. Сапер - это вообще заразная игра, на которую можно часы убивать, и она не требует ни скорости, ни еще чего-то особенного, чего нет в бейсике. Увлекает похлеще многих технично реализованных, но глупых игр на ассемблере. Одного моего знакомого даже исключили за это из института - он прогуливал пары и бегал играть в компьютерный класс - в сапера и "королевство".

"Взбесившиеся роботы" тоже хорошо и динамично получилось конвертировать, жаль только распространения им дать не получилось. Но может кто-то еще их делал на Спектруме, кроме меня.

Так что время все-таки подтвердило пригодность бейсика.

Чушь. У ассемблера на выходе - чистый код (можно по шагам отслеживать в эмуляторе) и листинг (можно вешать рядом с эмулятором для проверок).
И что, сидеть и вручную скрупулезно проверять? Ты-то сам часто так делаешь?

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

Большинство задач в ассемблере спокойно решаются без косвенной адресации к переменным.
Да, не самым эффективным способом, но РЕШАЮТСЯ. Начинающему достаточно.
Что, предлагаешь писать программы на ассемблере без использования косвенной адресации, чтобы не глючили?

Прекрасно. Как насчет вывода на экран символа? Я уже не говорю про сообщение. Можешь написать такую программу без косвенной адресации, которая может вывести произвольный символ в произвольную позицию на экране?

Следовательно - косвенная адресация НЕ нужна "постоянно и везде"
Ты это еще не доказал. Вот как будет вывод символа на приведенных выше условиях - тогда поговорим.

А вторые - с макросредствами по мере их изучения. В ЧЕМ ПРОБЛЕМА?
Проблема в том, что прежде, чем делать вторые шаги, надо сделать первые, а без макросредств (поскольку они еще не изучены) это становится затруднительным.

Контрпример - Lethargeek, человек чудовищно ленивый, вялый, сонный и слабовольный :p
Провозился пару часов (потому что набирал машинный код ручками во встроенном мониторе)
Адреса в дисплейном файле обнаружил методом тыка (мануалов не было)
Что еще за встроенный монитор, это о каком компьютере идет речь?

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

Ты так полностью и не рассказал свою историю овладения программированием - давай тогда полностью ее проанализируем, что и когда начиналось. Если уж твой пример детально рассматривать.

С калькулятором же сработало
И что, считаешь, что и с коровой сработает? Ну давай, попробуй :)

Или я скажу, что в бейсике тоже "постоянно требуется косвенная адресация"
Например, даже в случае простейшего "PRINT AT VarX, VarY;VarChar$"
Это не косвенная адресация. Это, по аналогии с ассемблером, прямая адресация. Типа LD A,(varX), LD A,(varY). Независимо от значений переменных в данном примере невозможна порча информации в других переменных или в тексте самой программы.

Косвенная адресация - это LD (HL),A. В зависимости от значения HL возможна порча чего угодно. В бейсике полных аналогов нет, есть приблизительный LET m(i)=a, но в случае неправильного значения i возможна порча только содержимого массива m, а остальные переменные или текст программы не будут затронуты.

А по-русски - "проверки ПРИ выполнении"
В самом деле, так переводится красивее. Хотя не во всех контекстах применимо. Например, нельзя сказать: "Я вставил в программу проверки при выполнении", поскольку смысл искажается, будто бы я вставил в программу эти проверки во время того, как программа выполнялась.

А словосочетание "проверки времени выполнения" с чьей-то нелегкой руки стало общеупотребительным термином. Даже гугл-переводчик с русского на английский правильно перевел, там явно в базе было забито данное словосочетание.

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

Когда есть только ассемблер - то компьютер ведет себя даже бесполезнее, чем калькулятор. Там хотя бы умножать можно и синусы вычислять, предварительно не изучая, что такое полиномы Чебышева.

Не придуривайся. Сразу станет несмешно, когда то же самое сложение будет в цикле.
Это ты не придуривайся. Мы вроде рассматривали программу, состоящую из одного сложения, а не цикла, забыл? И потом, чтобы сложение стало в цикле, надо сначала изучить, что такое цикл! Ты что, забыл, что когда-то этого не знал?

А у человека цель напейсать какашку и успокоиться?
У тех, кто "напейсать" - не знаю.

А у тех, кто первый раз хочет написать игру и делает первые шаги в программировании - цель стоит написать хоть какую-нибудь игру, чтобы стало понятно, что это ему под силу. Ну и заодно освоить некоторые концепции программирования. Эти первоначальные цели в рамках бейсика достигаются.

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

Это необходимые издержки производства. Программы выбрасываются даже в соответствии с хорошо проработанными планами. Например, Arun Kishan из микрософт в одной своей лекции рассказывает, как разработчики ядра винды, чтобы внести в него существенные изменения и не напороть глюков, приняли поэтапный план внесения этих изменений, что подразумевало разработку большого количества вспомогательного кода, который весь в конце концов был выброшен. И был достигнут успех.

Разуй глаза

Вынь бананы из ушей

И палец изо рта
Это твои аргументы?

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

Изучать "PRINT a+b*COS(c)" - БЕСПОЛЕЗНО
Обоснуй, почему бесполезно. В играх что, арифметические выражения не встречаются? И косинусы тоже?

Личный опыт, что ли? Ты застрял на мелочах в ассемблере и сбежал на бейсик?
В том числе и личный опыт. Некоторые мои проекты застряли на ранних стадиях разработки, т.е. на вылизывании мелочей. Если бы эти мелочи были уже реализованы кем-то другим или входили в базовый набор средств разработки (как операторы бейсика) - то возможно, эти проекты и увидели бы свет.

Что за страшные приемы так важны для понимания короткой строчки "CALL PRINT"?
Тролль.

У меня нет слов.

С помощью одной короткой строчки CALL PRINT на ассемблере невозможно напечатать сообщение или тем более значение выражения.

Выработка чувства достаточности

Можно. Но, во-первых, время потратил зря, во-вторых - сформированы вредные привычки
Какого еще чувства достаточности, зачем его вырабатывать?

Почему время зря потратил? Какие именно сформированы вредные привычки? Откуда уверенность, что эти же привычки не сформируются при работе с ассемблером?

А короткие никому на GUI не упали
Начинать обучение программированию с написания сразу длинных программ, минуя короткие? Ты часом не болен?

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

Segfault

09.01.2011, 04:47

Польза от сп-бейсика изза того что он вшит в ПЗУ и готов к работе через секунду несомненно есть.

Но она кончается через неделю, сужу по себе - не дебил, но скажем так технующий гуманитарий :) Ты понимаешь что очутился в песочнице и дальше хочется большего, но ты просто стопоришься и вместо вертикального спуска в компьютерные шахты начинаешь бессмысленное брожение по горизонтальным бейсик-лабиринтам,

А нужно спускаться, преодолевать страх

Для этого уже нужна хорошая книга по внутреннему устройству компа, примитивное изложение архитектуры, упор на прерывания, порты-ввода вывода, работы с периферией. А такие книжки как назло пишут в сухом стиле учебника алгебры и кажется что авторы пишут не для тебя, пионэра, а для своих коллег - чтобы те их не засмеяли...

Barmaley_m

09.01.2011, 05:25

Современный макроассемблер является чем захочешь
Он является структурным языком программирования?

Но что тогда задает стиль программирования, ассемблер или макросы?

Или мы ожидаем, что начинающий в ассемблере и программировании вообще сразу сможет создать макросы, которые превратят ассемблер в структурный язык?

И в паскале GOTO жив и здоров
И что, от этого что-то меняется? От этого паскаль перестает быть структурным языком программирования? Или ассемблер становится им?

Ты бы определился - так "отсутствуют" или все-таки "поддерживает"
Желающий понять - поймет, желающий спорить - сделает вид, что не понял.

Разве что +3, только в них можно отображать ОЗУ в 0-16К
Нет, это был именно +2, там к системному разъему был подключен контроллер TR-DOS и теневое ОЗУ.

(то есть полностью похерить совместимость с обычным Спеком)
Совместимость полностью сохранилась на уровне Спека +2 с дисковым интерфейсом. Теневое ОЗУ включалось по записи в определенный порт.

Между прочим, на дворе 2011 год, на столе песюк!
И что? От этого перестало быть возможным написать интересную игру на спековском бейсике?

Это ты не понимаешь, ЗАЧЕМ это БЫЛО нужно и ПОЧЕМУ
Зачем что было нужно? Ты о чем вообще?

Аттеншен! Ду ю рид ми? Але, гараж? Кто нибудь здесь спрашивал про "сложные численные алгоритмы"?
Численные методы - это один из примеров сложных алгоритмов, которые лучше всего поддаются отладке на интерпретируемых языках, желательно - со встроенными графическими средствами. Кроме численных методов существуют и другие сложные алгоритмы, а для начинающего программиста и то, что для нас с тобой кажется простым, может оказаться сложным.

В играх (не демах) встречаются сложные алгоритмы, например, для реализации интеллекта "врагов". Их немыслимо отладить изначально на ассемблере.

Если кто не в курсе, были заданы вопросы "Подскажите пожалуйста, На каких языках пишутся игры"

и "С чего нужно начинать, что-бы написать примитивную игру с простой черно-белой графикой?"
Бейсик удовлетворяет ответу на оба поставленных вопроса - это во-первых.

А теперь поведай мне, нахрена в простых игрушках регрессионный анализ?
Это был пример сложных алгоритмов, которые даже для профессионалов представляют трудности в наладке, но тем не менее хорошо поддаются наладке на таких языках, как бейсик. Что подчеркивает мощь этого языка с точки зрения наладки алгоритмов.

Эти "пониматели" хоть бы заголовок прочли сначала :rolleyes:
К тебе это относится в первую очередь. Ты начал этот спор, который сам же и увел далеко от исходной темы.

---------- Post added at 05:25 ---------- Previous post was at 04:50 ----------

Я не раз видел результат применения "бейсикового" подхода к программированию на других языках- одна огромная стартовая функция и миллиард глобальных переменных.
А ты уверен, что люди именно из-за бейсика начали использовать подобный подход? Может быть они просто, увидев удобства глобальных переменных, стали применять их повсеместно, полагая, что раз такое средство в языке имеется и кажется удобным - то почему бы его не применять при всяком удобном случае?

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

Неужели неизвестно?
1) Через стек
2) Передавая указатель на эти переменные.
Пункт 2 наверно сводится к пункту 1, потому что ведь сам указатель тоже надо как-то передать. Так что, небыдлокодеры передают параметры только через стек?

Lethargeek

09.01.2011, 06:55

Что угодно, на Спеке свет клином не сошёлся.
То есть ничего на Спеке ты назвать не можешь. Так я и думал. :D

Нельзя. Как и для ассемблера, чтобы начать программировать в машинном коде, нужно освоить сразу целый ряд новых абстракций. Для бейсика достаточно двух-трёх, основанных на уже известных из реальной жизни.
Подробней, пжалста. А то я-то думаю, что важнейшие ассемблерные "абстракции" рядовому спектрумисту и так известны.

Изучение 3х или 4х PC-шных программ вместо одного ПЗУ-шного бейсика. К тому же, язык bat-файлов - ещё один язык программирования, который тоже придётся изучать. (И я бы не назвал такую связку "дружественной". Удобной при определённом опыте - и то с трудом. ) Это вообще за гранью понимания предмета спора.
Ну когда ж вы перестанете изобретать несуществующие трудности?
Эмулятор уже известен, загружать в него снапшоты умеет каждый.
Монитор-дебагер? Распечатай списочек кнопок и повесь над экраном.
Ассемблер? Что там сразу-то надо изучать, кроме кучки обязательных директив?
bat-язык не нужен, я вот не знаю. Да там текст в три строчки.
Наконец, если что неясно - спроси на форуме!

Я имел ввиду не для мониторинга, а для программного ввода/вывода.
Ты писал: изучать программирование с их использованием
Для простых игрушек-то поначалу много не понадобится

Особливо с учётом опыта программирования ПМК.
...
Человек после ПМК знает почти всё, что нужно для изучения ассемблера любого процессора.
Человек до ПМК ничего не знает. Ииииии? :v2_conf2:
ЧЕМ изучение с нуля ПМК отличается от изучения с нуля машинных кодов Z80?
Там ведь тоже самое - арифметика, регистры, подпрограммы, ветвления, режим адресации... :v2_dizzy_tired2:
Да еще обратная запись с манипуляциями со стеком :v2_wacko: ПМК еще сложней Z80 покажется!
Только числа десятичные вещественные новичкам понятнее, но и все, пожалуй.

То, что отдельные личности, в силу определённого склада ума и течения жизни, сумели первым делом осилить ПМК (не факт, что с полпинка), никак не доказывает, что любому начинающему программировать стоит сразу изучать ассемблер.
Повторю: ПМК освоили сотни тыщ (если не миллионы) рядовых компутерно-неграмотных обывателей
Даже глюки научились юзать себе на радость :v2_dizzy_turn:

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

---------- Post added at 06:55 ---------- Previous post was at 06:52 ----------

(с Бармалеем разберусь отоспавшись)

Vitamin

09.01.2011, 12:02

А ты уверен, что люди именно из-за бейсика начали использовать подобный подход? Может быть они просто, увидев удобства глобальных переменных, стали применять их повсеместно, полагая, что раз такое средство в языке имеется и кажется удобным - то почему бы его не применять при всяком удобном случае?
Говорю за те случаи, с которыми сталкивался. На мой вопрос "почему ты так сделал?" (имеется в виду глобальные переменные и т.п.) был ответ "ну я когда-то на бейсике так писал, все работало".

Тут, мне кажется, дело в том, что кроме собственно учебников паскаля, надо читать еще книги вроде Кернигана и Плоджера о хорошем стиле программирования. Хоть данная книга базируется и на фортране - языке, не очень располагающем к структурированию программ - концепции, изложенные в ней, помогают и сегодня всем, кто старается совершенствоваться в данном деле.
И откуда начинающий программист догадается, что книги, содержащие исходники на неизвестном (а по слухам и весьма устаревшем) языке- правильный источник знаний?
Если уж на то пошло, есть более современные руководства по хорошему стилю программирования.

Пункт 2 наверно сводится к пункту 1, потому что ведь сам указатель тоже надо как-то передать. Так что, небыдлокодеры передают параметры только через стек?
А регистры уже отменили?

Spectramine

09.01.2011, 15:39

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

Подробней, пжалста. А то я-то думаю, что важнейшие ассемблерные "абстракции" рядовому спектрумисту и так известны.
Ну-ну. Поподробней, пожалуйста. Какие важнейшие ассемблерные абстракции рядовому спектрумисту "и так" известны?

Ну когда ж вы перестанете изобретать несуществующие трудности?
Эмулятор уже известен, загружать в него снапшоты умеет каждый.
Монитор-дебагер? Распечатай списочек кнопок и повесь над экраном.
Ассемблер? Что там сразу-то надо изучать, кроме кучки обязательных директив?
Кучку обязательных директив, как минимум. Да, несуществующие трудности - разобраться с дебаггером+ассемблером+эму лятором+их согласованием - это новичку просто как два байта переслать. (Я бы, если уж на то пошло, рекомендовал бы эмулятор со встроенным ассемблером и мощным отладчиком, например EmuZWin. Но необходимость разбираться с ними всё равно остаётся).

bat-язык не нужен, я вот не знаю. Да там текст в три строчки.
Наконец, если что неясно - спроси на форуме!
Спрашивать можно, только если имееешь представление, о чём спрашивать. А когда всё непонятно, и не спросишь.

Ты писал: изучать программирование с их использованием
Для простых игрушек-то поначалу много не понадобится
Для простых игрушек на асме понадобится как минимум изучить RST10 и опрос клавиатуры.

Повторю: ПМК освоили сотни тыщ (если не миллионы) рядовых компутерно-неграмотных обывателей
Даже глюки научились юзать себе на радость :v2_dizzy_turn:
А чё не миллиарды? :) Освоили, потому что на тот момент альтернатив не было. Но это были довольно продвинутые обыватели, к тому же не все из них освоили именно программирование, большинство просто научилось вводить программы и работать с ними.

Так любой язык сам по себе ему не помощник - книжки пускай читает
И неважно даже, на каком языке в них идут примеры, только суть важна
Не скажи, бейсик просто-таки провоцирует на написание простейших игр. А ассемблер - на "да ну его." Но литература важна, конечно. Только даже изучив инфоркомовский трёхтомник по программированию на асме, писать игры будет очень нелегко - из-за объёма работы, сразу сваливающейся на тебя при программировании простейших задач. Без изучения чужого кода более-менее приличную игру написать на асме просто нереально.

Barmaley_m

09.01.2011, 16:26

И откуда начинающий программист догадается, что книги, содержащие исходники на неизвестном (а по слухам и весьма устаревшем) языке- правильный источник знаний?
Возможные варианты: 1) по наставлению препода; 2) по совпадению имени одного из авторов с именем одного из авторов языка C, если читатель недавно осваивал язык C по книге Кернигана и Ритчи и оценил доходчивость изложения и ценность содержащейся в книге этих авторов информации.

Если уж на то пошло, есть более современные руководства по хорошему стилю программирования.
Я надеюсь. Ту книгу привел просто как пример лучшего, что читал сам на эту тему. Страуструп тоже учит хорошему стилю программирования, но это более тяжелое чтение.

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

А регистры уже отменили?
Нет, я просто постеснялся о них спрашивать, чтобы меня не назвали быдлокодером :) Ведь ты перечислил только стек и указатель (через стек).

А регистры по сути являются теми же глобальными переменными. В бейсике тоже можно назначить переменные с именами bc, de, hl, и зарезервировать их для целей передачи аргументов и результатов функций.

Стек необходим только для рекурсии, но это достаточно экзотическая ситуация, чтобы начинающий не беспокоился о том, что ему скоро понадобится этот прием.

---------- Post added at 16:26 ---------- Previous post was at 16:20 ----------

То есть ничего на Спеке ты назвать не можешь. Так я и думал. :D
Конкретно на Спеке просто нет нормальных компиляторов и интерпретаторов никаких языков, кроме бейсика и ассемблера.

Если расширить кругозор до границ использования процессора Z80, то рисуется турбо паскаль для CP/M. Более чем годный компилятор с редактором впридачу, очень рекомендуется для изучения и повседневного использования.

Vitamin

09.01.2011, 17:28

Возможные варианты: 1) по наставлению препода; 2) по совпадению имени одного из авторов с именем одного из авторов языка C, если читатель недавно осваивал язык C по книге Кернигана и Ритчи и оценил доходчивость изложения и ценность содержащейся в книге этих авторов информации.
Раз уж в процесс обучения вмешался сферический препод в вакууме, то как он допустил, что студент не знает элементарщины?
В моем случае все банально- контрактник просто покупал лабы/сессии. Дополз до диплома и понял, что неправильно выбрал профессию.

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

Нет, я просто постеснялся о них спрашивать, чтобы меня не назвали быдлокодером Ведь ты перечислил только стек и указатель (через стек).
Указатель через стек я не перечислял. Не надо делать неверных выводов.

А регистры по сути являются теми же глобальными переменными. В бейсике тоже можно назначить переменные с именами bc, de, hl, и зарезервировать их для целей передачи аргументов и результатов функций.
Притянуто за уши.

Стек необходим только для рекурсии, но это достаточно экзотическая ситуация, чтобы начинающий не беспокоился о том, что ему скоро понадобится этот прием.
Имхо, не стоит путать стек как структуру данных и стек как область памяти.

Barmaley_m

09.01.2011, 18:00

Раз уж в процесс обучения вмешался сферический препод в вакууме, то как он допустил, что студент не знает элементарщины?
В моем случае студент изначально не знал данных вещей, а препод его обучал. По-моему это нормальная ситуация. Для того и предназначены институты и университеты. Если человек сразу все знает - зачем ему учиться?

В моем случае все банально- контрактник просто покупал лабы/сессии. Дополз до диплома и понял, что неправильно выбрал профессию.
Тоже бывает. Но только при чем тут конкретно бейсик? Тут ведь явно руки были кривые, а не инструмент в них.

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

Указатель через стек я не перечислял. Не надо делать неверных выводов.
А через что же тогда передается сам указатель в рассмотренном тобой примере?

Притянуто за уши.
Отнюдь. Поясни принципиальную разницу между регистрами и глобальными переменными?

Имхо, не стоит путать стек как структуру данных и стек как область памяти.
Я и не путал. Просто, при реализации рекурсии нужен стек в том или ином виде.

Vitamin

09.01.2011, 18:32

В моем случае студент изначально не знал данных вещей, а препод его обучал. По-моему это нормальная ситуация. Для того и предназначены институты и университеты. Если человек сразу все знает - зачем ему учиться?
Структурное программирование (процедуры/функции) изучаются на самых ранних этапах курса программирования. А разные сложные алгоритмы- ближе к концу. Итого вопрос- как препод допустил, что студент делает сложные вещи, но не знает элементарщины?

Тоже бывает. Но только при чем тут конкретно бейсик? Тут ведь явно руки были кривые, а не инструмент в них.
Скажем так. Бейсик- для начинающих. А еще начинающие крайне подвержены синдрому Golden Hammer. Со всеми вытекающими.
Разумеется, в роли бейсика может быть и любой другой язык. Но если этот другой язык довольно развит, то это будет всяко лучше.

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

А через что же тогда передается сам указатель в рассмотренном тобой примере?
Как удобно. Либо через стек, либо через регистр. Это уже неважно.

Отнюдь. Поясни принципиальную разницу между регистрами и глобальными переменными?
С точки зрения функционала "хранение набора байт" конечно никакой. А с точки зрения предназначения- очень большая.

Я и не путал. Просто, при реализации рекурсии нужен стек в том или ином виде.
Для рекурсии в смысле перевызова функции или рекурсии в смысле рекурсивных алгоритмов?

moroz1999

09.01.2011, 19:33

Какбе не вдаваясь в детали вашего спора, посмею заметить, что проявленное впечатляющее упорство (http://zx.pk.ru/showpost.php?p=347810&postcount=62) достойно на мой взгляд лучшего применения :)
Детализация спора рвёт мозг!

Spectramine

10.01.2011, 17:40

Кстати. У меня когда-то была хорошая переводная книга по Бейсику для начинающих, большого формата (~ 40х25 см), с ламинированной обложкой, в твёрдом перелёте, с почти детскими иллюстрациями, изданная ещё в СССР. У меня её замутили, а сейчас хотелось бы найти её в инете, но я не помню названия, поиск в гугле пока ничего не дал. Может, у кого есть или была такая книга, подскажете название?

null_device

10.01.2011, 19:39

На Virtual TR-DOS в раздел books смотрели? А сколько в ней было страниц? И какой бейсик ("спектрумовский" или вообще) и только ли он там описывался?

Spectramine

10.01.2011, 20:21

Посмотрел, нету. Страниц сколько не помню, но она не была толстой. Бейсик не спектрумовский, чистый (спектрумовский очень близок к нему), описывался только Бейсик. Стиль изложения был рассчитан на подростковую аудиторию, в картинках вроде бы были роботы. И вроде бы это была книга из какой-то серии.

null_device

10.01.2011, 20:25

Оч. похожа на "Бейсик - это просто?"

Spectramine

10.01.2011, 20:34

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

Spectramine

11.01.2011, 01:50

Вспомнил! "Осваиваем микрокомпьютер", ч.2. (http://www.burnlib.com/x/osvaivaem-mikrokomp-yuter-kniga-2/) (Бейсиком в названии не пахнет, поэтому сразу не нашёл и не вспомнил).
У книги есть первая часть (http://www.burnlib.com/x/osvaivaem-mikrokomp-yuter-kniga-1/), в которой рассказывается о устройстве компьютера, его основных применениях, и немного о программировании и о Бейсике. Неплохие книги для начинающих разбираться в программировании, если пропускать то, что уже известно и понятно.

Barmaley_m

11.01.2011, 16:00

Точно, отличная книжка, я ее тоже помню!

Там еще такие жучки классные везде нарисованы. Как бы намекают на то, что будет досаждать программисту всю его сознательную жизнь :)

Lethargeek

12.01.2011, 06:22

Ты сам когда-нибудь или кто-то из твоих знакомых натыкался на этот баг? Я - никогда, хотя на бейсике на Спеке в свое время сделал немало. Сравнивать дробные числа на равенство - это плохая практика, от которой нас преподы предостерегали на самых первых лекциях. Так что данный аргумент не может считаться достаточным для отвержения бейсика в качестве инструмента программирования, в том числе игр.
Еще как может. Ибо явный баг, коим даже примитивные калькуляторы не страдают.

Вагон и маленькая тележка. Часть из них упоминалась и на этой ветке. Диктатор, президент, хлебное королевство, Титан (Ground force zero). Когда-то я сделал на бейсике сапера - тоже можно было вполне сносно играть по настроению. Даже друзья в гостях играли. Сапер - это вообще заразная игра, на которую можно часы убивать, и она не требует ни скорости, ни еще чего-то особенного, чего нет в бейсике. Увлекает похлеще многих технично реализованных, но глупых игр на ассемблере. Одного моего знакомого даже исключили за это из института - он прогуливал пары и бегал играть в компьютерный класс - в сапера и "королевство"
Маленький децкий самосвальчик одноразовых однотипных клонов
На бейсике видал два сапера, оба вусмерть тормозные

И что, сидеть и вручную скрупулезно проверять? Ты-то сам часто так делаешь?
Нахрен скрупулезно? Только что последнее (проги, знаешь ли, удобнее писать по кусочкам)

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

Что, предлагаешь писать программы на ассемблере без использования косвенной адресации, чтобы не глючили?
Просто не заигрываться с регистрами

Прекрасно. Как насчет вывода на экран символа? Я уже не говорю про сообщение. Можешь написать такую программу без косвенной адресации, которая может вывести произвольный символ в произвольную позицию на экране?
А ты на бейсике? :v2_devil:

Ты это еще не доказал. Вот как будет вывод символа на приведенных выше условиях - тогда поговорим.
Вот как выучишь, что такое косвенная адресация - тогда и поговорим
Погроммист профессианальный мля

Проблема в том, что прежде, чем делать вторые шаги, надо сделать первые, а без макросредств (поскольку они еще не изучены) это становится затруднительным.
Что становится затруднительным? Записать в колонку несколько свежевыученных команд? :v2_dizzy_facepalm:

Что еще за встроенный монитор, это о каком компьютере идет речь?
Ты не поверишь, о Спектруме (была такая ПЗУха со встроенным монитором и турбо-лоадером)

И потом, ты что, никогда ничего не программировал на бейсике (или других языках высокого уровня) прежде, чем взяться за ассемблер? Что, даже простейшей программы не написал? Из принципа что ли?
На Спеке - нет, не писал. Из-за бессмысленности. Так, только потестировал.
В школе, ясен пень, приходилось. Впрочем, калькулятор-то все равно был раньше.

И что, считаешь, что и с коровой сработает? Ну давай, попробуй
Ну давай, пригони проверенную корову, принеси учебник по доению, я попробую :v2_dizzy_biggrin2:

Это не косвенная адресация. Это, по аналогии с ассемблером, прямая адресация. Типа LD A,(varX), LD A,(varY). Независимо от значений переменных в данном примере невозможна порча информации в других переменных или в тексте самой программы.
Учи матчасть, профессионал. Это именно что КОСВЕННАЯ адресация - "адрес" назначения (назначения, блин! даже направление пересылки ты перепутал) НЕ константа и в самой команде не фигурирует. Он вытаскивается откуда-нибудь из памяти. А прямая адресация вот она:

PRINT AT 3,7;
(ладно, третий параметр пока не трогаем, а то будет новый спор о символах и массивах)

Косвенная адресация - это LD (HL),A. В зависимости от значения HL возможна порча чего угодно. В бейсике полных аналогов нет, есть приблизительный LET m(i)=a, но в случае неправильного значения i возможна порча только содержимого массива m, а остальные переменные или текст программы не будут затронуты.
Нуичо? Это было страшно при царе Горохе, в случае отладки на реале
С эмулятором как-то похрен (даже легче ловится, если код испорчен)
Или вставь в отладочный вариант проверку и не страдай

Когда есть только ассемблер - то компьютер ведет себя даже бесполезнее, чем калькулятор. Там хотя бы умножать можно и синусы вычислять, предварительно не изучая, что такое полиномы Чебышева.
Человек хотел вообще-то писать игрушки
Синусов хватает на песюке

Это ты не придуривайся. Мы вроде рассматривали программу, состоящую из одного сложения, а не цикла, забыл?
Мы рассматриваем пригодность для игрушек, забыл?

И потом, чтобы сложение стало в цикле, надо сначала изучить, что такое цикл!
А на бейсике не надо?

А у тех, кто первый раз хочет написать игру и делает первые шаги в программировании - цель стоит написать хоть какую-нибудь игру, чтобы стало понятно, что это ему под силу. Ну и заодно освоить некоторые концепции программирования. Эти первоначальные цели в рамках бейсика достигаются.
Что какашки всем тут под силу, и так понятно

Сразу никто не потянет проект, претендующий на название "лучшей игры года". Все равно придется начинать с чего-нибудь попроще и неприметнее, что скорее всего не получит широкого распространения и будет заброшено. Хоть на бейсике, хоть на ассемблере. Ты-то сам много своих ассемблерных программ 15-летней давности используешь по сравнению с тем, сколько их было тобой написано в те времена? И сколько в этих программах осталось кода 15-летней давности?
Я 15 лет назад кодил на песюке. Все работает, старый код почти весь остался :D

Это необходимые издержки производства. Программы выбрасываются даже в соответствии с хорошо проработанными планами. Например, Arun Kishan из микрософт в одной своей лекции рассказывает, как разработчики ядра винды, чтобы внести в него существенные изменения и не напороть глюков, приняли поэтапный план внесения этих изменений, что подразумевало разработку большого количества вспомогательного кода, который весь в конце концов был выброшен. И был достигнут успех.
Бейсик проще сразу выбросить :v2_dry:

Это твои аргументы?
Это способ для тебя их увидеть

Полезно изучать и знать вообще все, только это неконструктивный совет, он не дает руководства человеку о том, как в реальных условиях можно все это осуществить и не разочароваться раньше, чем будет достигнут результат.
Лишь бы сам "достигнутый результат" не разочаровал
А то в горку заберешься, а вид ацтойный

Обоснуй, почему бесполезно. В играх что, арифметические выражения не встречаются? И косинусы тоже?
Ты наверно страшно удивишься, но какой-нибудь там рекс или саботер обошлись простейшими вычислениями без косинусов :v2_dizzy_roll:
И вместе с ними over 9000 спектрумовских игрушек, кроме разве что отдельных экземпляров с трехмерной графикой

В том числе и личный опыт. Некоторые мои проекты застряли на ранних стадиях разработки, т.е. на вылизывании мелочей. Если бы эти мелочи были уже реализованы кем-то другим или входили в базовый набор средств разработки (как операторы бейсика) - то возможно, эти проекты и увидели бы свет.
Ну так ты же с бейсика начинал :v2_tong2:

Тролль.

У меня нет слов.

С помощью одной короткой строчки CALL PRINT на ассемблере невозможно напечатать сообщение или тем более значение выражения.
Это кто здесь троль? Я напомню, что всего лишь отвечал на:

А трудности есть, потому что программа на ассемблере даже для простейших действий, вроде вывода на экран сообщений, уже становится настолько большой, что требует специальных приемов, облегчающих ее понимание человеку.
Очевидно, жертвам бейсика невдомек, что на отлаженные нормальные процедуры (не уродские гоу сабы) при наборе текста или просмотре листинга можно не отвлекаться (и вообще вынести их нахрен в отдельный файл) :rolleyes:

Какого еще чувства достаточности, зачем его вырабатывать?
Например, чтоб не лезть куда попало с косинусом наперевес :v2_dizzy_biggrin2:

Откуда уверенность, что эти же привычки не сформируются при работе с ассемблером?
Глядя на тебя, укрепляется уверенность, что привычки точно сформируются после бейсика :rolleyes:
А то хоть надежда будет

Начинать обучение программированию с написания сразу длинных программ, минуя короткие? Ты часом не болен?
А ты сам здоров? У тебя походу смысловые галлюцинации

Не зря потратил, потому что он научился основам программирования и при этом получил результаты, которыми может гордиться - собственные работающие программы, которые делают не тривиальные вещи, вроде вывода на экран символа, а что-нибудь поинтереснее.
Угу. Целых два десятка символов UDG-графики :v2_laugh:

skyther

12.01.2011, 06:37

Терзают смутные сомнения, что тут БК сам с собой разговаривает...

Lethargeek

12.01.2011, 07:08

что тогда задает стиль программирования, ассемблер или макросы?
Возможности, в нем заложенные

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

И что, от этого что-то меняется? От этого паскаль перестает быть структурным языком программирования?
Паскаль в очумелых ручках привыкших к бейсику вмиг перестает быть структурным без всяких GOTO :v2_laugh:

Или ассемблер становится им?
Стал уже давно

Желающий понять - поймет, желающий спорить - сделает вид, что не понял.
А сморозивший - прикроется высокопарными фразами :rolleyes:

Нет, это был именно +2, там к системному разъему был подключен контроллер TR-DOS и теневое ОЗУ.
Вот я и спрашиваю: ну при чем тут Спектрум? Внешние железки, чтобы что-то скомпилировать (а то и чтоб запустить)
Твой паскаль умеет компилировать полноценные программы для работы на обычном Спеке БЕЗ наворотов?
Впрочем, даже в этом случае лучше подыскать песюковый кросс-компилер

Совместимость полностью сохранилась на уровне Спека +2 с дисковым интерфейсом. Теневое ОЗУ включалось по записи в определенный порт
...и Спек в CP/M режиме переставал быть Спеком, что и требовалось доказать

И что? От этого перестало быть возможным написать интересную игру на спековском бейсике?
Ту же самую? Нет, не перестало :D

Зачем что было нужно? Ты о чем вообще?
*терпеливо* Да о том же, что ты очень сильно переоцениваешь

...возможность исполнения команд языка во время останова, возможность вычисления выражений, распечатки на экран значений переменных в "человеческом" виде, а также внесения изменений в отлаживаемую программу БЕЗ необходимости ее перекомпиляции и перезапуска с нуля
в отрыве от современности :v2_dizzy_grandfathe

Численные методы - это один из примеров сложных алгоритмов, которые лучше всего поддаются отладке на интерпретируемых языках, желательно - со встроенными графическими средствами
И еще желательней - не на Спектруме

Кроме численных методов существуют и другие сложные алгоритмы, а для начинающего программиста и то, что для нас с тобой кажется простым, может оказаться сложным.
Fgsfds... это к чему вообще? Предлагаешь начинающим начинать с отладки сложных алгоритмов? :v2_wacko:

В играх (не демах) встречаются сложные алгоритмы, например, для реализации интеллекта "врагов". Их немыслимо отладить изначально на ассемблере.
После бейсика очень многое кажется НЕМЫСЛИМЫМ :v2_laugh:

Бейсик удовлетворяет ответу на оба поставленных вопроса - это во-первых.
Отрицательному - это во-вторых :v2_tong2:

К тебе это относится в первую очередь. Ты начал этот спор, который сам же и увел далеко от исходной темы.
Не вали с больной головы на здоровую
Это ты здесь начал плакать о косинусах и высасывать из пальца мнимые мегатрудности

Lethargeek

12.01.2011, 07:31

Терзают смутные сомнения, что тут БК сам с собой разговаривает...
Юлик, ТЫ?! :v2_ohmy:

psb

12.01.2011, 07:43

Ибо явный баг, коим даже примитивные калькуляторы не страдают.

умникам следовало бы знать, что это не баг бейсика! это фича вообще, глобальная. этим не только калькуляторы страдают (а особенно примитивные!!!), это вообще везде такой "баг". учи математику, знаток:)

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

null_device

12.01.2011, 08:31

Меня вообще удивляет, как можно шесть страниц "меряться сингулярностями" и "жонглировать какашками"?! Было произнесено много "громких" слов, перечисленна масса "доводов" в пользу "верного и единственного" подхода в програмировании. Из всего этого, полезного, для себя я не увидел. Извиняюсь за копипасту, но, по-существу..
процесс работы компьютера заключается в выполнении программы, то есть набора вполне определённых команд во вполне определённом порядке. Машинный вид команды, состоящий из нулей и единиц, указывает, какое именно действие должен выполнить центральный процессор. Значит, чтобы задать компьютеру последовательность действий, которые он должен выполнить, нужно задать последовательность двоичных кодов соответствующих команд. Программы в машинных кодах состоят из тысячи команд. Писать такие программы - занятие сложное и утомительное. Программист должен помнить комбинацию нулей и единиц двоичного кода каждой программы, а также двоичные коды адресов данных, используемых при её выполнении. Гораздо проще написать программу на каком-нибудь языке, более близком к естественному человеческому языку, а работу по переводу этой программы в машинные коды поручить компьютеру. Так возникли языки, предназначенные специально для написания программ, - языки программирования.

Имеется много различных языков программирования. Вообще-то для решения большинства задач можно использовать любой из них. Опытные программисты знают, какой язык лучше использовать для решения каждой конкретной задачи, так как каждый из языков имеет свои возможности, ориентацию на определённые типы задач, свой способ описания понятий и объектов, используемых при решении задач.

Всё множество языков программирования можно разделить на две группы: языки низкого уровня и языки высокого уровня.

К языкам низкого уровня относятся языки ассемблера (от англ. to assemble - собирать, компоновать). В языке ассемблера используются символьные обозначения команд, которые легко понятны и быстро запоминаются. Вместо последовательности двоичных кодов команд записываются их символьные обозначения, а вместо двоичных адресов данных, используемых при выполнении команды, - символьные имена этих данных, выбранные программистом. Иногда язык ассемблера называют мнемокодом или автокодом.

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

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

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

Lethargeek

12.01.2011, 09:14

умникам следовало бы знать, что это не баг бейсика! это фича вообще, глобальная. этим не только калькуляторы страдают (а особенно примитивные!!!), это вообще везде такой "баг".
Бугога! Стало быть, явная ошибка в первом же знаке после запятой при расчетах с внутренним двоичным представлением вещественных чисел это "глобальная фича"? Математику здесь нужно явно учить тебе :v2_laugh:

и да. будь добр, покажи-ка свои поделочки на асме для спека? посмотрим, как ты круто управляешься с асмом. а то балаболить-то мы все горазды.
Поищи по форуму, все лежит, что счел нужным выложить
Кстати, как насчет твоих поделок на синклер-бейсике?
Только не забудь убрать из них расово неверный инпут с инкеем :v2_devil:

Извиняюсь за копипасту, но, по-существу..
А по существу - эмулятор плюс кросс-ассемблер это нынче сразу целый завод железобетонных конструкций с ультразвуковым контролем качества по сравнению с кустарными шлакоблоками синклер-бейсика. Кое-кто здесь до сих пор не может понять, что предмет дискуссии - преимущества и недостатки определенных средств разработки в определенное время, а не сферобейсики в синклервакууме.

Vadim

12.01.2011, 09:33

На ассемблере все-таки писать сложнее по следующим причинам:
Отвечаю, хоть и несколько запоздало (у вас тут дискуссия уже далеко зашла). По Вашим, Barmaley_m, ответам вижу полное непонимание написания программы на ассемблере. Все время проекция оного с метода написания на бейсике. Я ж написал, что принцип одинаков. Но нельзя понимать это буквально. Одинаков подход к написанию, но методы отладки и использования дополнительных процедур разные. Итак, по порядку:

На ассемблере все-таки писать сложнее по следующим причинам:
1) Ошибки в программах имеют тяжелые последствия, вплоть до сброса компьютера. Раньше, когда программы сохранялись на кассетах, это серьезно задерживало процесс, пока перемотаешь кассету и загрузишь заново ассемблер
/skip/skip/skip///
То же касается компиляторов: ошибки в компилированных программах часто приводят к сбросу компьютера.

Во первых, я не имел ввиду написание программы на асме в магнитофонном варианте, хотя и так я писал года до 1994-го. В Gens3 потом в 4-м. И ещё в Zeus. Сохранял на кассету текст перед компиляцией и запуском. Да. Думать приходилось сильнее, а не тут же жать на кнопку запуска. Я далее это поясню.

2) Невозможно остановить в любой момент ассемблерную программу и посмотреть ее состояние с той же легкостью, как это можно сделать с бейсик-программой.

Совершенно несогласен. Во первых, в отладчиках (под которыми предполагается отлаживать программу которую мы пишем) есть режим эмуляции кода. Есть точки останова. Хотя я в 1992-1994гг ими не пользовался, а пользовался (как тут уже писали) монитором прошивки "турбо-90", вывел себе проводок от 17-й ноги Z80 и быстро проводил проводком по радиатору БП. Комп вылетал в монитор. Вот вам и прерывание. Да, иногда все напрочь висло (о этом случае я писал в Ревюшке'93), но это не смертельно. А вот с бейсиком беда. остановить его мы можем (хотя используя несложный прием мы это можем отключить), но как посмотреть состояние программы? Нужно проверять значения всех переменных (глобальных) вводя кучу команд... Сложнее чем в отладчике.

3) Некоторые ошибки в программах на ассемблере поздно себя проявляют, делая трудным их обнаружение.
Вот тут вообще не понял. С моей т.з. в этом отношении и бейсик и асм одинаковы. Ведь как пишется программа? Мы продумываем структуру, блоки, их взаимосвязь, а потом уже начинаем реализовывать задуманное. Грубо говоря приводя программу к структурированному виду, когда вся программа это иерархическая система "черных ящиков". У каждого ящика есть вход и выход. Нам надо реализовать функционал, потом о реализации можно забыть. Важно что бы ящик делал то, что нам надо. Делаем "внутренности" раскладывая сложные алгоритмы в набор более простых, вернее пишется скорее всего наоборот (уже когда структура программы проработана) пишем сначала базовые процедурки, потом на их основе более сложные и т.д. В бейсике процесс написания абсолютно аналогичен. И в паскале также. Предвижу возражения, что дескать "мы так не писали, писали как получится". В том то и дело, что если делать так, то ничего серьезного не напишешь. Это обычная тактика новичков, кто учится программировать. Бейсик для этого и предназначен, но и на нем можно писать так как я описал выше.

4) Отсутствие разборщика выражений, из-за этого - трудности с вычислениями. Арифметика с плавающей точкой доступна начинающим только после изучения
Тут согласен, но отчасти. Разборщик выражений в бейсике логической ошибки в программе не увидит и будет сидеть начинающий проггер и тупить над программой, а ошибка может быть и в алгоритме вычислений и в логике, да где угодно. А в асме без библиотки арифметических функций делать нечего. Нужен набор процедур, или самописный (что лучше всего, сначала писать их, учить асм, учить команды проца) или чей-то. Здесь ещё хочу сказать, что нужны базовые знания по программированию, в области арифметики. Т.е. точное представление двоичной и шестнадцатеричных систем исчисление, представлять себе деление, вычитание, сравнение, умножение, деление чисел. Знать алгоритмы быстрого деления и умножения сдвигом. В бейсике это не нужно, но знать программисту это всё равно надо. Такое мое мнение.

5) Отсутствие процедур ввода и вывода.Использование бейсиковских процедур требует изучения и понимания куда более сложных вещей, чем то, как пользоваться операторами PRINT и INPUT.

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

Можно пользоваться подпрограммами ZX-Basic, или опять же иметь свои наработки. Это полезней со всех сторон. Необходимо понимать как работает машина. Начинающие писать на бейсике этого сознательно лишаются. Они изучают некую абстрактную бейсик-машину. Со своим экраном, клавой и памятью в виде переменных и массивов. С одной стороны в этом и был смысл бейсика, абстрагировать обучающихся от железа, что бы они учили процедурное программирование. Но в этом и грабли на будущее. Т.е. зацикливаться на чем то одном не надо. Пописал человек 2-3 месяца на бейсике, более-менее изучил его и надо двигаться далее. Изучать в первую очередь архитектуру машины, основы программирования на асме (то что я выше описывал) и примерно через полгода уже можно приступать к написанию первых процедур. И уже позднее программ. Т.е. смысл сказанного мной таков. Имея знания о архитектуре компа, имея опыт написания программ процесс написания на бейсике и на асме будет похож. Примерно как снимать очень дорогой камерой изменяя и контролируя несколько десятков параметров и телефоном, нажимая на одну кнопку. Получаем и соотв. результаты.
Нужно не только изучать сам бейсик или асм, а изучать программирование, архитектуры проца, конкретной машины, видоподсистемы. Представлять себе как можно реализовать алгоритмически аркадную игру (типа Exolon, R-Type, River Raid, Crazy Cars). Как написать движок. И уже потом можно браться за инструмент. Бейсик, Паскаль, Си или асм. Есть примеры игр совершенно другого плана, изометрия, 3D (Dark Side и прочие), адвентюры с графикой и без и т.д. И каждый тип имеет свой движок, свои особенности. Не зная их, не понимая даже при идеальном знании Паскаля или Си игру не напишешь. Поэтому вопрос заданный в теме мне не понятен. Вернее понятен, что автор некорректно поставил вопрос из-за не понимания вопросы программирования игр вообще.

А ещё хотелось бы сказать, что проблемы освоения асма, паксаля или Си возникали ранее у тех, кто начинал с бейсика из-за скомканности обучения всему что связано с компьютерами. То кидаются в сторону алгоритмов, то учим бейсик, то устройство компа обзорно. В этом проблема. Масса отрывочных сведений, мало связанных между собой. Человеку который видит это всё впервые сложно усвоить всю инфу и адекватно её воспринять. Однобокое, неполное понимание в дальнейшем создает проблемы. Некоторые люди в упор не воспринимают hex числа, при том пишут программы на асме. Вот вам привет из zx-бейсике (в других реализациях бейсика hex числа есть). Т.е. если изучать всё планомерно и последовательно, что из себя представляет компьютер и с чем его едят, то и проблем будет меньше.

psb

12.01.2011, 10:37

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

Поищи по форуму, все лежит, что счел нужным выложить
мы разговариваем не по форуму, а конкретно в этой теме, выложи ссылки на свой софт. или ты слить решил по тихому?

По Вашим ответам вижу полное непонимание написания программы на ассемблере.
забавно это читать:) тов. Barmaley_m более чем в адеквате:) и про асм знает не по наслышке:) просто рассуждает не только смотря на свой личный опыт.

остановить его мы можем (хотя используя несложный прием мы это можем отключить), но как посмотреть состояние программы? Нужно проверять значения всех переменных (глобальных) вводя кучу команд... Сложнее чем в отладчике.
вводя команды типа LIST, PRINT, ты нажимаешь несколько кнопок. для того чтобы в отладчике посмотреть содержимое памяти или код, ты точно так же нажимаешь несколько кнопок.
только вот досада: хочешь ты посмотреть переменные A,B,C и строку D$, в бейсике ты так и пишешь: PRINT A,B,C,D$ - получаешь значение переменных в остановленный момент. а что ты делаешь в асме? для начала тебе надо знать адрес твоих переменных. где ты его берешь? ищешь кусок кода с этим адресом? или наугад среди кучи данных (по т.н. eyecatcher), зная что вслед за чем лежит? или открываешь листинг асма и ищешь там свою переменную? не слишком ли???
далее, нашел ты переменную, 2 байта, а там D5 38. ЭТО СКОЛЬКО???
вы будете дальше настаивать на удобстве дебаггера??

Ведь как пишется программа? Мы продумываем структуру, блоки, их взаимосвязь, а потом уже начинаем реализовывать задуманное. Грубо говоря приводя программу к структурированному виду, когда вся программа это иерархическая система "черных ящиков".
и в этом кроется ошибка в ваших рассуждениях:) новичок так не делает никогда! он просто не умеет продумывать структуру, не понимает никаких черных ящиков. потому он и новичок. а теперь представь, что человек этого не умеет и переосознай:)
если человек си или паскалем хоть как-то вынужденно начинает программу структурировать, то в асме руки полностью развязаны и просто так он этого делать ни за что не будет. а в современных ЯВУ как раз идет тенденция связывания рук, чтобы нельзя было делать всё что в голову взбредет.

А в асме без библиотки арифметических функций делать нечего. Нужен набор процедур, или самописный (что лучше всего, сначала писать их, учить асм, учить команды проца) или чей-то.
правильно! новичку их сначала тока надо где-то взять, потом РАЗОБРАТЬСЯ как их использовать (это для вас сейчас это просто!), а потом юзать.
а писать такое новичку - да большинство нахрен пошлет программирование сразу, т.к. результата не будет ну очень долгое время.

Т.е. точное представление двоичной и шестнадцатеричных систем исчисление, представлять себе деление, вычитание, сравнение, умножение, деление чисел. Знать алгоритмы быстрого деления и умножения сдвигом.
это ты хочешь предложить новичку?:))))) я подозреваю что этого даже монстр асма Lethargeek не знает... бейсик (и любой алгоритмический язык) тем и хорош, что ты заморачиваешься только с алгоритмом, но не с борьбой с машиной.
нехватку регистров в асме уже никто не помнит? память короткая?:) ах да, у Lethargeek особый ламерский метод складывать все в память...

С одной стороны в этом и был смысл бейсика, абстрагировать обучающихся от железа, что бы они учили процедурное программирование. Но в этом и грабли на будущее.
нет здесь граблей. направления в программировании бывают разные и не стоит всех заставлять проходить свой путь. если ты системщик - тебе полезно знать то, о чем ты пишешь - алгоритмы деления, умножения, как работает комп. если же ты прикладник - в гробу видал все эти премудрости, твоя задача - решать поставленную задачу ЛЮБЫМИ методами. есть невероятное количество людей, никогда не изучавших асм, но делающих такие вещи, которые мы тут все вместе взятые можем не асилить. само по себе программирование - ничто и никому не нужно, оно становится значимым только в применении к какой-то области. и именно программированию учиться лучше точно не на асме. асм нынче вообще мало кому нужен.

Пописал человек 2-3 месяца на бейсике, более-менее изучил его и надо двигаться далее. Изучать в первую очередь архитектуру машины, основы программирования на асме (то что я выше описывал) и примерно через полгода уже можно приступать к написанию первых процедур. И уже позднее программ.
вот здесь вряд ли бы кто стал спорить, все верно.

Некоторые люди в упор не воспринимают hex числа, при том пишут программы на асме. Вот вам привет из zx-бейсике (в других реализациях бейсика hex числа есть).
не соглашусь. пишут так потому что тупо привычка считать в десятичной системе. сложно обычному человеку вообще понимать другую систему.

Т.е. если изучать все планомерно и последовательно, что из себя представляет компьютер и с чем его едят, то и проблем будет меньше.
если писать все на асме, максимально продумывая, то винда и все остальное будет просто летать, даже на древних компах! и не глючить! ибо писавший будет досконально знать что и как он сделал. хехе:) но в реальном мире - это УТОПИЯ! это не реально ни на 0.001%. просто жизни не хватит и людей.

Lethargeek

12.01.2011, 11:39

бред несешь. разберись вот как раз с "внутренним двоичным представлением вещественных чисел".
Лол, с каким? С тем, в котором 1/2<>0.5? Уймись уже, балаболка!
Или мне тебе напомнить алгоритм деления в столбик для первоклашек? :v2_dizzy_facepalm:
Чтобы ты сумел поделить пятерку на десятку в двоичном коде
сосчитав на пальцах, сколько битов нужно для вычислений

мы разговариваем не по форуму, а конкретно в этой теме, выложи ссылки на свой софт. или ты слить решил по тихому?
Ты УЖЕ слил по-тихому, даже слова не сказав о своих поделках на бейсике :v2_dizzy_stop:

вводя команды типа LIST, PRINT, ты нажимаешь несколько кнопок. для того чтобы в отладчике посмотреть содержимое памяти или код, ты точно так же нажимаешь несколько кнопок.
Лично я обычно нажимаю Step или Step Over и вижу все :cool:
Кстати, как на бейсике организовать обычную трассировку?
Или как следить за ходом прорисовки, не потеряв саму прорисовку?
Будешь дальше настаивать на удобстве отладки ручками под бейсиком?

вот досада: хочешь ты посмотреть переменные A,B,C и строку D$, в бейсике ты так и пишешь: PRINT A,B,C,D$ - получаешь значение переменных в остановленный момент.
Вот досада: хочешь посмотреть переменные в ЛЮБОЙ момент - и не можешь :v2_tong2:

далее, нашел ты переменную, 2 байта, а там D5 38. ЭТО СКОЛЬКО???
Кинуть в калькулятор или просто кликнуть кнопочку decimal так трудно? :rolleyes:
Кстати, перед этим не мешает для начала определиться, нужно ли оно вообще в десятичном виде

Vadim

12.01.2011, 12:00

забавно это читать тов. Barmaley_m более чем в адеквате и про асм знает не по наслышке

Судя по его постам в других ветках я в курсе, но тут какие-то неуместные сравнения.

или наугад среди кучи данных (по т.н. eyecatcher), зная что вслед за чем лежит?
Если честно, то никогда глубоко не отлаживал своих программ. Всегда "отладку" делал в уме, смотря на текст программы. И уж если совсем затык (было пару раз) то уже пользуюсь отладчиком. А вообще переменные можно держать в одном месте. Да и для отладки конкретного участка не надо их смотреть десятками.

D5 38. ЭТО СКОЛЬКО???
Это 38D5, если переменная 16 бит. Мне совершенно не важно сколько это в десятичной системе.

нет здесь граблей.

Есть. Сам через такое прошёл. Умея программировать на basic очень трудно понять "как же работает комп". Если нет описания архитектуры от общего к частному и наоборот от простого к сложному. Когда нет описаний как работает скелет программы которая гоняет спрайты по экрану zx-spectrum. Как она отрабатывает логику. Не зная этого новичек пишет дикие проги на бейсике. Ужасающие по своей безграмотности. Многие, кстати, перейдя потом в маш.код, ассемблер, многое принесли из тех ужасов бейсика.

направления в программировании бывают разные и не стоит всех заставлять проходить свой путь.
Как раз я и предлагаю идти не моим путем, а более другим :-) более коротким и эффективным. А то что направления бывают разные я в курсе. Можно только 3D графикой заниматься и не знать про аппаратуру вообще ничего (мы говорим в разрезе ZX-Spectrum и подобных машин, а не современных монстров), но знать при этом как же "работает комп" всё же полезно. Сколько я видел программистов, учившихся в свое время на ПОВТ'е и которые совершенно не представляли, зачем нужен проц, что такое прерывания, как обменивается программа с внешним миром данными и прочее. При этом они писали базы данных простейшие, используя для сортировки метод "пузырька" и ни секунды не сомневались что они и есть программисты....
Ещё пример где-то прочитал не помню уже, что программистка одна сдавала программу на паскале, писала на роботрон 1715, в TP 3.0 некую базу данных, так вот, у неё при выводе результата были всполохи символов искореженных, она всё не могла от них отделаться а потом плюнула и всё списала на неисправность компа, а между тем причина была в том, что луч пробегал во время вывода символов. Он ж "реальный" программист, зачем ей знать такие тонкости....

нехватку регистров в асме уже никто не помнит? память короткая?
Вот представь - Нет! Никогда у меня не было случаев, что бы регистров не хватало, что капец. Нет, конечно бывает, что для красивой и быстрой реализации нужен ещё один 8-и или 16-и битный регистр. Приходится извращаться, но это очень редко бывает. По первости, когда я пришёл из бейсика это было нормой. Я вообще не понимал как можно при таком малом кол-ве регистров хоть что-то писать. Почему так думал? Да потому что работал шаблон мышления - регистры это почти переменные бейсика, только своеобразные. А это ведь не так! Вообще не так! И таких вот шаблонов (у меня по крайней мере была) куча. О этих граблях я и писал. Конечно, если человек всю жизнь будет писать алгоритмы на лиспе или прологе то все вышеописанное ему ни к чему. Но я то думал, что мы говорим о спектруме. О программировании под него. Или нет?

бейсик (и любой алгоритмический язык) тем и хорош, что ты заморачиваешься только с алгоритмом, но не с борьбой с машиной.

Да это понятно. Много раз уже это сказано.

пишут так потому что тупо привычка считать в десятичной системе. сложно обычному человеку вообще понимать другую систему.

Я как предлагал выше? Сначала изучаем двоичную и 16-и ричную системы. И не так что "аааа, да понятно всё" и забыли вопрос. Сколько я людей ловил на том, что реально они не понимают. Нужно кристальной чистоты понимание и уже потом двигаться дальше. Это как если мы толком не одели коньки то учиться кататься бесполезно.

---------- Post added at 15:00 ---------- Previous post was at 14:51 ----------

если писать все на асме, максимально продумывая, то винда и все остальное будет просто летать, даже на древних компах! и не глючить! ибо писавший будет досконально знать что и как он сделал. хехе
Это почти слово в слово говорил и я и другие люди мне, когда такой вопрос обсуждали ещё лет 10 назад. Так оно. Хоть все и не реально на асме написать, но побольше чем сейчас - вполне реально, а то сейчас даже драйверы для видях пишут на Си. И получаем кривоту кривейшую. Не раз уже встречал случаи когда производитель так и не избавлялся от фатальных ошибок, бросал продукт и начинал "новую версию".
Напоминаю, мы о спектруме говорим, а не о ПЦ.

psb

12.01.2011, 12:51

Или мне тебе напомнить алгоритм деления в столбик для первоклашек?
Чтобы ты сумел поделить пятерку на десятку в двоичном коде
сам подучи.

10 LET a=1/2
20 LET b=5/10
30 LET c=0.5
40 IF a=b THEN PRINT "a=b"
50 IF c=b THEN PRINT "c=b"
60 IF c=a THEN PRINT "c=a"

что же, интересно, напечатается? А??? балабол хренов.

Ты УЖЕ слил по-тихому, даже слова не сказав о своих поделках на бейсике
слил? молодец:) стрелы не переводи, спрашивал я тебя, т.к. это ты кидаешь понты о своей крутости в асме и умению пользоваться дебаггером. вот и покажи, чего ты добился. а уже потом мы решим про мой (или не мой) бейсик.

Лично я обычно нажимаю Step или Step Over и вижу все
ну это только потому что ты долбан. объясняю: глюк может возникать на N-ной секунде/минуте/часе, а не сразу. ты все это время жмешь Step? БАЛАБОЛ!!! мы все эти методы знаем отлично, как и отладчик в анриле, и понтануться асмовскими работами можем гораздо гораздее, но понтуешься тут ты - у тебя почему-то все легко и просто. наверное потому что ничего серьезного-то и не делал. покажи свой код!

Или как следить за ходом прорисовки, не потеряв саму прорисовку?
пример выдуман из ничего. могу на такое ответить - поставлю паузу в цикл. устроит? меня устроит. как начнет неправильно рисовать - остановлю и все посмотрю.

хочешь посмотреть переменные в ЛЮБОЙ момент - и не можешь
ты идиот:) нет смысла их смотреть в ЛЮБОЙ момент:)

Кинуть в калькулятор или просто кликнуть кнопочку decimal так трудно?
где ты ее кликнешь? в анриле? БАЛАБОЛ!
калькулятор - лишнее действие. бейсик побеждает. и ты про нахождение адреса не сказал.

А вообще переменные можно держать в одном месте. Да и для отладки конкретного участка не надо их смотреть десятками.
и вот лежит у тебя 50 переменных. ты даже знаешь их порядок. и каждый раз ты будешь вычислять смещение относительно чего-то... а после изменения проги адреса поплывут... в бейсике этой проблемы нет в принципе!

Это 38D5, если переменная 16 бит. Мне совершенно не важно сколько это в десятичной системе.
ах, ну конечно не важно, если только тебе вообще не интересно о чем это. а за каждой переменной имеется какой-то физический смысл! и иногда нужно оценить что-то в принятых физических величинах! если ты считал количество оставшихся свободных тактов за прерывание, число 38D5 тебе много скажет?

Умея программировать на basic очень трудно понять "как же работает комп".
при программировании на бейсике (даже создании игры!!!) такой задачи не стоит вообще никогда!!! не придумывайте!

Не зная этого новичек пишет дикие проги на бейсике. Ужасающие по своей безграмотности. Многие, кстати, перейдя потом в маш.код, ассемблер, многое принесли из тех ужасов бейсика.
1. потому что он новичок, так положено.
2. ты правда думаешь, что начав с асма он будет писать как-то иначе??? не будет! он не знает как надо, и язык тут не при чем.

но знать при этом как же "работает комп" всё же полезно.
видишь, полезно, но абсолютно не обязательно.

При этом они писали базы данных простейшие, используя для сортировки метод "пузырька" и ни секунды не сомневались что они и есть программисты....
они и были программисты, просто не такие как ты:)

а между тем причина была в том, что луч пробегал во время вывода символов
ты уверен, что это была работа с бд, а не текстовая демо/интра? :)))))) просто в таких задачах таких проблем не бывает! на выдумку похоже, ибо чтобы увидеть луч - надо постоянно что-то менять.

Никогда у меня не было случаев, что бы регистров не хватало, что капец. Нет, конечно бывает, что для красивой и быстрой реализации нужен ещё один 8-и или 16-и битный регистр.
имхо, конечно, но асм имеет смысл тогда, когда нужна скорость. а скорости не будет, если постоянно писать/читать память, чтобы всегда хватало регистров. так что такими методами программинга вы делаете УГ, а не нормальный ассемблерный код. это мое мнение.

Я как предлагал выше? Сначала изучаем двоичную и 16-и ричную системы.
ну, как на информатике:) и после этого все начинают ее ненавидеть.
зато я знаю много людей, которые не зная как работает комп, пишут программы для работы с сетью, с базами данных и т.д. даже 3д-игры!!! ОНИ ПРЕКРАСНО ДЕЛАЮТ СВОЮ РАБОТУ! а то, что вы хотите навязать им свои познания в системах счисления, в том как работает комп - это ваша беда.

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

Lethargeek

12.01.2011, 13:23

сам подучи.

10 LET a=1/2
20 LET b=5/10
30 LET c=0.5
40 IF a=b THEN PRINT "a=b"
50 IF c=b THEN PRINT "c=b"
60 IF c=a THEN PRINT "c=a"
Лучше так:

10 IF 1/2<>0.5 THEN PRINT "psb dolban"
RUN
psb dolban
0 OK, 10:2

слил? молодец
Ты? Да :v2_tong2:

спрашивал я тебя, т.к. это ты кидаешь понты о своей крутости в асме и умению пользоваться дебаггером
Не гони. Я как раз писал, что ленив, небрежен и неусидчив. Потому и выбрал асм+эмуль :v2_devil:

ну это только потому что ты долбан. объясняю: глюк может возникать на N-ной секунде/минуте/часе, а не сразу. ты все это время жмешь Step?
А ведь там написано про Step Over... но долбаны же не дочитывают полстрочки :rolleyes:

пример выдуман из ничего. могу на такое ответить - поставлю паузу в цикл. устроит? меня устроит. как начнет неправильно рисовать - остановлю и все посмотрю.
Ахахах... и все это время стучишь по кнопке? :v2_laugh:
Кстати, паузы поставить придется ручками в тормозном редакторе

ты идиот нет смысла их смотреть в ЛЮБОЙ момент
Да ну? Вот отлаживает новичок, например, питона. И тут опа: змейка хвост отбросила и дальше ползет обрубком. Ичоделать? Куды паузу-то ставить?

где ты ее кликнешь? в анриле? БАЛАБОЛ!
Например в СПИНе :v2_tong2: правда, и там тоже не пригодилось

калькулятор - лишнее действие. бейсик побеждает
Бейсик PRINT verylongbutselfdescriptivevariablename - куча кнопочек
Калькулятор - копипаста или нумпад
Бейсик всасывает, причмокивая

Doktor

12.01.2011, 13:40

Уважаемые Lethargeek и psb,

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

Vadim

12.01.2011, 14:18

зато я знаю много людей, которые не зная как работает комп, пишут программы для работы с сетью, с базами данных и т.д. даже 3д-игры!!!

На спектруме? или где? На ПЦ все разбито по уровням. Мощность проца позволяет. Операционка написана до них. Все сетевые сервисы, транспорт, всё готово. Они пишут на ЯВУ различных, даже в плане видеовывода для них и там все подготовлено, даже библиотки и годы наработк готовы. Любые прачки и домохозяки могут программить. Ессно они не знают как работает комп. Но мы не о них говорим.

psb

12.01.2011, 15:03

Любые прачки и домохозяки могут программить. Ессно они не знают как работает комп. Но мы не о них говорим.
да, мы пытаемся говорить о том, что не обязательно нужны все эти знания.

---------- Post added at 17:03 ---------- Previous post was at 16:50 ----------

Лучше так
умыл, но все равно это не правильно идеологически. так делать НЕЛЬЗЯ, хоть на бейсике, хоть на асме. сделал как нельзя и получил хрень - молодец, ССЗБ.

Потому и выбрал асм+эмуль
ну так и покажи, чего добился своим выбором. застеснялся что ли?

А ведь там написано про Step Over...
если проявляется через секунды-минуты - это не имеет значения

и все это время стучишь по кнопке?
Кстати, паузы поставить придется ручками в тормозном редакторе
не надо стучать!
а тебе бряки поставить в неудобном дебаггере:)
одинаково.

Да ну? Вот отлаживает новичок, например, питона.
и где ты видишь здесь ЛЮБОЙ момент? он вполне конкретный, и как раз может далеко не сразу проявиться, так что твои Step Over пролетают. а раз пролетают - вы оказываетесь в одинаковых условиях.

Например в СПИНе
ты уже определись в чем ты там пишешь. а то запрыгал...

Бейсик PRINT verylongbutselfdescriptivevariablename - куча кнопочек
Калькулятор - копипаста или нумпад
бред. PRINT А :)
а у тебя нумпад с буквами? или сбалаболил опять?

но вашу бы энергию да в полезное дело...
не боись, полезное дело делается, лично у меня, а вот на полезные дела Lethargeek я бы поглядел.

Vitamin

12.01.2011, 15:28

да, мы пытаемся говорить о том, что не обязательно нужны все эти знания.
Но и палку перегибать не стоит. А то получаем армию погроммистов, не знающих даже основ программирования (не специфики работы железа или еще чего, а именно Computer Science).

psb

12.01.2011, 15:37

Но и палку перегибать не стоит. А то получаем армию погроммистов, не знающих даже основ программирования (не специфики работы железа или еще чего, а именно Computer Science).
так ведь часто именно это и надо бизнесу! т.е. есть задача, и эта задача идеально решается (пусть *****кодом, глюками, но быстро).

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

Vitamin

12.01.2011, 16:09

так ведь часто именно это и надо бизнесу! т.е. есть задача, и эта задача идеально решается (пусть *****кодом, глюками, но быстро).
Быстро решается, да долго аукается. Как показывает практика, фирмы, сэкономившие на разработке, теряют очень много на поддержке.

psb

12.01.2011, 17:49

согласен полностью:) только ведь у кого какая стратегия... многих это почему-то устраивает (и это можно понять, когда бабки интересуют в первую очередь).

Vitamin

12.01.2011, 18:45

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

http://insidecpp.ru/antipatterns/lava_flow/

Barmaley_m

12.01.2011, 22:45

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

Он проявляется только в экзотических случаях, когда некто специально желает проверить бейсик на предмет безглючности и сравнивает значения заведомо тождественных выражений. Если присвоить 0.5 и 1/2 переменным и потом их сравнить - результат будет правильный. Поэтому можно обоснованно считать, что этот баг практических препятствий к написанию программ на бейсике не представляет и в реальных (не надуманных) условиях не проявляется. В частности, я ни разу сам на него не напоролся, программируя на спектрумовском бейсике, да и о том, чтобы кто-то напоролся - тоже не слышал. А даже если это когда-то с кем-то произошло - то последствия заведомо не превышали последствия от глюка собственной программы на ассемблере.

Те, кто нашел этот глюк первыми (Ян Логан и Френк о хара) - они его нашли не случайно напоровшись, а детально анализируя код бейсика.

Маленький децкий самосвальчик одноразовых однотипных клонов
А чего ты ждешь от новичка, "Лучшей игры-2011" что ли?

На бейсике видал два сапера, оба вусмерть тормозные
Мой сапер отрабатывает нажатие клавиши "открыть квадрат" менее, чем за секунду. Собственно, там и делать-то ничего не надо, откуда взяться тормозам? А даже если программа тратит 2-3 секунды - то от этого играбельность "сапера" не зависит, так как человек тратит большее время на обдумывание следующего хода.

Нахрен скрупулезно? Только что последнее (проги, знаешь ли, удобнее писать по кусочкам)
Так что, по кусочкам пишешь программу, а потом сидишь и сравниваешь, правильно ли ассемблер ее компилировал? А потом еще раз, скомпилировал ли он правильно всю программу, потому что ведь по кусочкам могло сработать правильно, а всю - с ошибкой.

Лол, подробнее, пжалста - какого размера?
Посмотри дизассемблер ПЗУ от Логана и О'Хары - какого размера там подпрограмма RST 16. Своя программа, конечно, может быть и короче, но добрых 100 строк она может занять в зависимости от функциональности.

Просто не заигрываться с регистрами
А какие критерии? Где определено, что такое "заигрываться с регистрами"? И что, тогда точно не будет порчи памяти?

А ты на бейсике?
PRINT AT x,y;c$. Причем обращаю внимание: обращение к переменным x и y - это прямая (абсолютная), а не косвенная адресация. Неверные или даже специально злоумышленно подобранные значения переменных не могут привести к порче программы или ее данных. Теперь твой ход. Пожалуйста то же самое, без косвенной адресации, на ассемблере.

Собственно говоря, на бейсике нет необходимости решение указанной задачи реализовывать в виде подпрограммы, поскольку задача решается одной командой. Поэтому вместо присвоения переменным значений и вызова подпрограммы целесообразнее просто подставить команду PRINT AT в то место программы, где нужно вывести символ.

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

Погроммист профессианальный мля
Погроммистом я себя никогда не называл. Это твои домыслы. Что это за жаргон? "Погроммист", "напейсать"? Ты часом не антисемит?

Что становится затруднительным? Записать в колонку несколько свежевыученных команд? :v2_dizzy_facepalm:
Мы вроде говорили о более-менее ощутимых результатах от выполнения этих команд. А от "колонки свежевыученных" вряд ли даже буква на экране появится.

Ты не поверишь, о Спектруме (была такая ПЗУха со встроенным монитором и турбо-лоадером)
Я усмотрел из твоих ответов другим пользователям, что речь шла о некой прошивке "Турбо-90". Ну-ну. Только как после этого твой компьютер можно назвать Спектрумом, если быть столь же придирчивым в этом вопросе, как ты в вопросе о CP/M?

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

Учи матчасть, профессионал. Это именно что КОСВЕННАЯ адресация - "адрес" назначения (назначения, блин! даже направление пересылки ты перепутал) НЕ константа и в самой команде не фигурирует. Он вытаскивается откуда-нибудь из памяти. А прямая адресация вот она:

PRINT AT 3,7;
Это ты привел пример непосредственной адресации, когда обрабатываемая информация присутствует в самой команде. Пример на ассемблере - XOR 3. На бейсике аналогом непосредственной адресации является использование констант, вроде тех, что в твоем примере.

Когда же вместо обрабатываемой информации в команде присутствует ее адрес - то такая адресация называется прямой, или абсолютной. Пример на ассемблере - LD (VarX),A где VarX - константа. Тут адрес назначения (но не обрабатываемая информация) присутствует в самой команде. Аналог бейсика - LET x=a. В обоих случаях кроме переменной VarX, другая информация в памяти не может быть затронута.

А косвенная адресация - это, как я уже говрил, LD (HL),A. Без такой адресации в ассемблере немыслимо создание сколько-нибудь сложных программ, но именно эта адресация является самой "опасной", так как в случае неверного (по ошибке или умышленно) значения HL любая область памяти может быть испорчена (по меньшей мере, в пределах подключенных в данный момент страниц).

Нуичо? Это было страшно при царе Горохе, в случае отладки на реале
С эмулятором как-то похрен (даже легче ловится, если код испорчен)
Да нет, потенциальная порча текста программы и данных в произвольном месте никуда не ушла с приходом эмуляторов. Похожие проблемы имели бы место на бейсике, если бы там неаккуратная работа с переменными приводила бы к порче текста программы.

Или вставь в отладочный вариант проверку и не страдай
Данный прием тоже не снимает проблемы порчи текста программы и данных в произвольном месте.

Человек хотел вообще-то писать игрушки
Синусов хватает на песюке
Вот пускай и пишет, бейсик в помощь. Моя первая игрушка (называлась "Устный счет") использовала умножение. С теми знаниями, которыми я тогда обладал (еще не выучил ни циклов, ни GOSUB) на ассемблере такое бы не получилось. И вообще ничего бы не получилось, никакой игры. А у меня получилась игра. Простая, примитивная, но своя.

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

В программах на бейсике одиночные и даже в коротких циклах сложения не представляют никаких проблем. Взять тот же "Сапер". Ну не всегда нужна скорость. Иногда человек является фактором, делающим быстродействие излишним. Поиграй-ка в Sea Dragon на уровне Admiral :)

А на бейсике не надо?
На бейсике тоже надо, но еще до такого изучения человек может уже быть в состоянии написать свою игру на бейсике. То же касается ПМК, между прочим. Функции ввода и вывода тебе на нем чай не приходилось самому реализовывать.

Что какашки всем тут под силу, и так понятно
Да не всем, в том-то и дело! Не каждый может даже "какашечную" игру на бейсике или еще чем-то написать. Этому надо учиться. Долго и постепенно.

Я 15 лет назад кодил на песюке. Все работает, старый код почти весь остался
А много ли из этого кода используется в твоих программах последних лет?

Бейсик проще сразу выбросить
Не сразу. Он может многое дать прежде, чем станет ненужным.

Это способ для тебя их увидеть
Странный способ. От его применения мне (да и остальным скорее всего) не стало ясно, что же я должен был увидеть.

Лишь бы сам "достигнутый результат" не разочаровал
А то в горку заберешься, а вид ацтойный
Не волнуйся, не разочарует. Альпинисты начинающие ведь тоже на Эверест сразу не лазают. Начинают с мест попроще, и радости от покорения таких "невысоких" вершин у них не меньше. Потому что одно дело - когда кто-то, а другое дело - когда сам.

Barmaley_m

12.01.2011, 23:12

Ты наверно страшно удивишься, но какой-нибудь там рекс или саботер обошлись простейшими вычислениями без косинусов
И вместе с ними over 9000 спектрумовских игрушек, кроме разве что отдельных экземпляров с трехмерной графикой
Ну вот, ты признал, что косинусы в играх на Спектруме все же встречаются. Почему тогда, с твоей точки зрения, является бесполезным их изучение?

Кроме того, вычислять косинусы не всегда нужно во время работы игры (или демы), иногда их можно вычислить заранее и хранить в таблице. Так вот, а как и на чем готовить такую таблицу? Бейсик предоставляет отличную возможность для этого, поэтому изучение косинусов и арифметики вообще в бейсике может сослужить программисту хорошую службу.

Ну так ты же с бейсика начинал :v2_tong2:
Этот весь аргумент сводится к показыванию языка, которое ты совершил в конце фразы. Покажи мне на того, кто что-то делал и у кого нет неудачных проектов?

Это кто здесь троль? Я напомню, что всего лишь отвечал на:
Тролль по следующим причинам. Если вывод сообщения на экран на ассемблере ты сводишь к одному вызову "CALL PRINT", то с тем же успехом написание всей игры можно свести к "CALL GAME"! Но то же можно и на бейсике, оператором RUN! Набрал - и сразу игра запускается! Вот, оказывается, как просто игры-то писать!

Очевидно, жертвам бейсика невдомек, что на отлаженные нормальные процедуры (не уродские гоу сабы) при наборе текста или просмотре листинга можно не отвлекаться (и вообще вынести их нахрен в отдельный файл) :
Ты хочешь меня лично оскорбить, назвав жертвой бейсика? Очень показательно, ведь я в твой адрес подобных саркастических замечаний не отпускал. Но переход на личности - это верный признак отсутствия аргументов по существу :)

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

Например, чтоб не лезть куда попало с косинусом наперевес
А написанию игр это помогает? Или просто с косинусами не бегать помогает? Как эта твоя фраза относится вообще к теме? Опять аргумент в стиле "показать язык"?

Глядя на тебя, укрепляется уверенность, что привычки точно сформируются после бейсика :rolleyes:
А то хоть надежда будет
Попытка оскорбления вновь свидетельствует об отсутствии аргументов. А далее по тексту ты признаешь, что уверенности нет, что вредные привычки не будут сформированы программированием на ассемблере вместо бейсика. Имеешь лишь надежду. Ну вот и отлично. Что и требовалось доказать.

А ты сам здоров? У тебя походу смысловые галлюцинации
Аргумент в стиле: "сам дурак". По существу ответить нечего? Предлагаешь начать обучение программированию с написания длинных программ, вместо коротких?

Угу. Целых два десятка символов UDG-графики
Ты, наверно, чрезмерно (может быть принципиально) пренебрегал бейсиком, чтобы считать, что UDG-графика - это единственное, что на нем можно сделать. Уверяю тебя, это не так. Расширь свой кругозор.

---------- Post added at 23:12 ---------- Previous post was at 22:46 ----------

а вот на полезные дела Lethargeek я бы поглядел.
Не дави, здесь ему есть что показать. Сделал более быстрый движок, чем авторский, для отображения ландшафта в игре Sea Dragon. Это более чем достойно уважения.

Addison

13.01.2011, 00:24

С чего нужно начинать, что-бы написать примитивную игру с простой черно-белой графикой? Хотя бы для начала.

Я сам особо не писал игры, однако имею некоторый опыт программирования на Бейсике, Паскале и Ассемблере. В основном решал насущные прикладные задачи.
Однако если бы взялся писать игру, держался бы следующей концепции.

1. Задумка, сюжет, основная идея.
2. Графика.
3. Движок, если графика будет в игре подвижная.
4. Логика (искусственный интеллект).
5. Интерфейс.

От первого пункта зависит очень многое, наверное 80% успеха. Ведь даже при бедной графике, но при хорошей задумке можно получить шедевр!!! Но, возможно, для пробы пера игра должна быть простой и неизащренной в плане сюжета.
Графика обычно создается при помощи какого-либо графического редактора, например для Спектрума, это может быть Артстудио. Вполне можно разрисовать экраны, здесь же прикинут объем ОЗУ под это дело, предусмотреть архивацию. Если будет подвижная графика, прорисовать спрайты.
Для движения спрайтов необходим движок, его лучше писать на Ассемблере, но, в принципе, можно даже на Бейсике. Есть специализированный для этих целей Бейсик, так называемый Лазер Бейсик.
Логику можно писать на чем угодно - это уже не так принципиально.

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

В школе ребята успешно писали экономические стротегии на обычном штатном бейсике. Игры были довольно играбельны. Но из всего перечисленного там был только искусственный интеллект и интерфейс.

Странно, что они ленились использовать хотя бы стандартную графику пользователя для оформления...

Lethargeek

13.01.2011, 10:28

PRINT AT x,y;c$. Причем обращаю внимание: обращение к переменным x и y - это прямая (абсолютная), а не косвенная адресация
Не тупи! СМЫСЛ команды - обращение к экрану, не к переменным!
Покажи-ка нам тут "прямое (абсолютное)" обращение К ЭКРАНУ
ГДЕ ты здесь увидел хотя бы НЕПОСРЕДСТВЕННО указанные КООРДИНАТЫ?
Именно сами значения, а не ССЫЛКИ на них через переменные, ась?
(уж молчу про реальный экранный адрес, чтоб не портить аналогию)

Это ты привел пример непосредственной адресации, когда обрабатываемая информация присутствует в самой команде. Пример на ассемблере - XOR 3. На бейсике аналогом непосредственной адресации является использование констант, вроде тех, что в твоем примере
АДРЕС - это НЕ "обрабатываемая информация"
Непосредственным параметром в рамках аналогии может быть лишь явно заданный символ

Когда же вместо обрабатываемой информации в команде присутствует ее адрес - то такая адресация называется прямой, или абсолютной. Пример на ассемблере - LD (VarX),A где VarX - константа. Тут адрес назначения (но не обрабатываемая информация) присутствует в самой команде. Аналог бейсика - LET x=a. В обоих случаях кроме переменной VarX, другая информация в памяти не может быть затронута.
Ё-моё :v2_dizzy_facepalm: Если ты считаешь "PRINT AT x,y;c$" аналогом прямой адресации, то поведай мне, в какую же из двух цифровых переменных ПРЯМО перешлется символьное значение c$ - в X, в Y, или в обе сразу? :v2_laugh: Или все же символ (или его образ) должен (в том или ином виде) попасть не в сами переменные, а в некую область памяти, КОСВЕННО адресуемую данными переменными?

Комментировать остаток не вижу смысла, пока азов не поймешь

psb

13.01.2011, 12:16

Не дави, здесь ему есть что показать. Сделал более быстрый движок, чем авторский, для отображения ландшафта в игре Sea Dragon. Это более чем достойно уважения.
более чем? для новичка - безусловно, но ведь он не новичок?
и что мы видим в том коде скроллера?
1. жесткая манипуляция со стеком
2. прога пишет в область самой себя (меняет адреса в опкодах)
3. все жесточайше раскранчено в памяти

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

ГДЕ ты здесь увидел хотя бы НЕПОСРЕДСТВЕННО указанные КООРДИНАТЫ?
путаешь непосредственную и прямую адресацию. непосредственная - число, прямая - переменная, типа как Х.

в какую же из двух цифровых переменных ПРЯМО перешлется символьное значение c$ - в X, в Y, или в обе сразу?
говорю же, толстый жирный троллище!

Lethargeek

13.01.2011, 12:47

Непосредственная адресация
В команде содержится НЕ АДРЕС операнда, а непосредственно САМ ОПЕРАНД.

Прямая адресация
АДРЕС указывается непосредственно в виде некоторого ЗНАЧЕНИЯ,

Косвенная адресация
Адресный код команды в этом случае УКАЗЫВАЕТ адрес ячейки памяти, В КОТОРОЙ находится адрес операнда или команды.
http://ru.wikipedia.org/wiki/Методы_адресации

psb

13.01.2011, 13:06

Lethargeek, в вики-то правильно написано, а ты тупишь:)

Barmaley_m

13.01.2011, 13:26

http://ru.wikipedia.org/wiki/Методы_адресации
Ну наконец-то ты соизволил почитать матчасть. В этом свете посмотри на свое предыдущее сообщение и найди, где ты ошибался.

Ё-моё Если ты считаешь "PRINT AT x,y;c$" аналогом прямой адресации, то поведай мне, в какую же из двух цифровых переменных ПРЯМО перешлется символьное значение c$ - в X, в Y, или в обе сразу?
Успокойся, не надо паники. Команда PRINT AT x,y;c$ не производит запись в переменные x и y и c$. Она производит считывание из этих переменных. Адресация (любая) применяется ведь не только для записи, но и для считывания, правильно? В ассемблере для этих целей используются команды вида LD A,(VarX).

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

В случае неправильных значений во всех трех указанных переменных максимум что может произойти плохого - это порча содержимого экрана. Но уж никак не порча программы или содержимого переменных.

Или все же символ (или его образ) должен (в том или ином виде) попасть не в сами переменные, а в некую область памяти, КОСВЕННО адресуемую данными переменными?
Ты сейчас углубляешься в реализацию команды PRINT AT самим бейсиком. Но с точки зрения программиста на бейсике вся эта команда выполняется как одно целое. И последствия ее выполнения вполне четко ограничены, что никак не могут испортить программу или ее переменные. Мы с тобой знаем, что печать производится путем записи в экранную область, но начиная программировать на бейсике, нет необходимости даже понимать, что такое экранная область, как она устроена и где находится.

Если проводить аналогию с ассемблером - то допустим, мы выполняем команду LD (VarX),A. Эта команда использует прямую адресацию, поэтому не может изменить содержимое памяти где-либо, кроме адреса VarX. Но это только с точки зрения программиста данная команда выполняется как одно целое и имеет конкретные последствия. С точки зрения разработчика процессора, эта команда выполняется за много шагов. Сначала адрес VarX считывается из памяти и помещается во внутренний буферный регистр Z80 (MEMPTR), а потом во время записи в память процессор ставит на шину адреса содержимое этого регистра. То есть внутри процессора имеет место нечто, подобное косвенной адресации. Но для программиста это неважно до тех пор, пока процессор не вышел из строя.

Я надеюсь, ты не предлагаешь начинающим программистам на ассемблере изучать, как устроен процессор и как он выполняет "элементарные" команды?

ZEK

13.01.2011, 13:42

путаешь непосредственную и прямую адресацию. непосредственная - число, прямая - переменная, типа как Х.
вы все путаете это косвенно индексная адресация :)

Barmaley_m

13.01.2011, 13:56

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

и после этого он нам впаривает про какую-то структурность и правила хорошего тона в программировании?
Сам же понимаешь, что без всех этих трюков так быстро не получилось бы. Это высший пилотаж. Но это не исключает, что Lethargeek может писать на ассемблере и соблюдая хороший тон и пытаясь реализовать структурность средствами ассемблера. Хотя хорошую игру так тоже не напишешь. Медленно будет.

про ассемблер для новичков? про то, что у него все макросами сделано и проверяются границы, чтобы лишнего не записать?
Молодец, хорошо подметил! Ведь если, программируя на ассемблере, пытаться соблюдать хороший стиль всеми этими способами - то будет медленно, и игра мирового класса все равно не получится.

---------- Post added at 13:56 ---------- Previous post was at 13:49 ----------

вы все путаете это косвенно индексная адресация :)
Кажется, тролли начинают сбегаться на огонек.

Lethargeek

13.01.2011, 14:08

Ты сейчас углубляешься в реализацию команды PRINT AT самим бейсиком. Но с точки зрения программиста на бейсике вся эта команда выполняется как одно целое.
НЕТ. Это ТЫ "углубляешься в реализацию команды PRINT AT самим бейсиком". Я как раз рассматриваю ее "как одно целое". И вот в качестве единого целого на самом высоком уровне данная команда КОСВЕННО адресуется именно К ЭКРАНУ, а не к вспомогательным переменным. Повторяю: покажи мне, ГДЕ в команде "PRINT AT X,Y;c$" АДРЕС ЭКРАНА (я согласен даже "адресом" считать не реальный экранный адрес, а хотя бы координаты) указан в виде ЗНАЧЕНИЯ, а не ССЫЛОК на значение?

---------- Post added at 14:03 ---------- Previous post was at 13:58 ----------

Сам же понимаешь, что без всех этих трюков так быстро не получилось бы. Это высший пилотаж. Но это не исключает, что Lethargeek может писать на ассемблере и соблюдая хороший тон и пытаясь реализовать структурность средствами ассемблера.
Ты не поверишь, но в исходнике у меня сплошные макросы и короткие процедурки
ace210 не даст соврать ;)

Молодец, хорошо подметил! Ведь если, программируя на ассемблере, пытаться соблюдать хороший стиль всеми этими способами - то будет медленно, и игра мирового класса все равно не получится.
Все равно получится лучше, чем на бейсике :v2_tong2:

---------- Post added at 14:08 ---------- Previous post was at 14:03 ----------

вы все путаете это косвенно индексная адресация
главно что косвенно ;)

Barmaley_m

13.01.2011, 14:29

И вот в качестве единого целого на самом высоком уровне данная команда КОСВЕННО адресуется именно К ЭКРАНУ...

АДРЕС ЭКРАНА (я согласен даже "адресом" считать не реальный экранный адрес, а хотя бы координаты)
Ты предлагаешь экран рассматривать как массив? Ну хорошо, пусть будет так. С этой точки зрения команда PRINT AT x,y действительно обращается к этому массиву с помощью аналога косвенной адресации.

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

Все равно получится лучше, чем на бейсике :v2_tong2:
А вот в этом можно усомниться. Откуда у тебя такая уверенность?

главно что косвенная ;)
Рыбак рыбака видит издалека!

psb

13.01.2011, 15:20

Ведь если, программируя на ассемблере, пытаться соблюдать хороший стиль всеми этими способами - то будет медленно, и игра мирового класса все равно не получится.
именно что!
ассемблер на спектруме наоборот поощряет писать так, как "не правильно" :)

ГДЕ в команде "PRINT AT X,Y;c$" АДРЕС ЭКРАНА (я согласен даже "адресом" считать не реальный экранный адрес, а хотя бы координаты) указан в виде ЗНАЧЕНИЯ, а не ССЫЛОК на значение?
нет в бейсике никаких ссылок! всюду подмены понятий!
AT 10,20 на псевдокоде можно было бы записать так:
LD BC,#0a14
а AT x,y так:
LD BC,(XY)
или
LD B,(Y)
LD C,(X)
где здесь косвенная адресация??? вижу только прямую. а вот для вывода буквы на экран тебе сразу же говорили, что без косвенной никак!

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

Lethargeek

13.01.2011, 15:21

Хорошо, я согласен на бейсике поставить ограничение на произвольность координат. Пусть координаты будут фиксированные.
Да хоть бы и произвольные :rolleyes: Если уж "гуру кодинга" так буквально-узко понимают косвенность адресации, давай так: я за пару дней напишу "безопасную" процедурку вывода заданного символа в произвольную позицию на экране без единой "косвенной" команды "LD (reg),reg/val" и распечатаю с ее помощью короткое сообщение. Вы тогда (вместе с psb, чтоб уж сразу двух (кен)гуру одним ударом) публично покаетесь, признаете мою правоту, поставите в подпись текст "Бейсик вреден. Начинать на Спектруме надо сразу же с ассемблера", и советовать всем будете то же самое. Ежели не справлюсь - сам публично покаюсь, посыплю голову пеплом и поставлю в подпись текст, что круче бейсика в мире нету. :p

Ну, согласны? Жду официальных ответов. :v2_devil:

Wowik

13.01.2011, 15:29

Давайте просто на перегонки, один пишет фразу на экран на бейсике, другой на асме и кто быстрее.

ZEK

13.01.2011, 15:29

Кажется, тролли начинают сбегаться на огонек.
не бубни, ламерье, я пошутил в бейсике индексная адресация
имя переменной является ключом для поиска в табличке переменных - фактически индекс , а адрес таблички хранится в системной переменной басика VARS, так что адресацию можно назвать относительно-индексной :)

psb

13.01.2011, 15:36

да-да, а на уровне транзисторов вообще никакой адресации нет. не надо в крайности бросаться, да?

Sinus

13.01.2011, 15:38

ну дайте и мне шмякнуть что-нибудь :)

Lethargeek, а я могу написать программу на ассемблере (любом менее более нормальном спековском ассемблере, думаю даже GENS прокатит), которая выводит надписть (правда фиксированную надпись и по фиксированным координатам) вообще без комманд LD!

upd:

даже два варианта, один немного читерский (так как там будет использоваться косвенно-регистровая адресация (не знаю точно как по-русски, в вики какая-то фигня написана; по англицки - register indirect)), второй - абсолютно без читов.

Lethargeek

13.01.2011, 15:38

Давайте просто на перегонки, один пишет фразу на экран на бейсике, другой на асме и кто быстрее.
А давайте сразу 100500 произвольных фраз? :D

psb

13.01.2011, 15:41

без единой "косвенной" команды "LD (reg),reg/val"
и без самомодификации кода? ДАВАЙ!

---------- Post added at 17:41 ---------- Previous post was at 17:38 ----------

вообще без комманд LD!
думаю, что ты загнул:) фиксированный адрес-то загружать будешь...

Lethargeek

13.01.2011, 15:41

Lethargeek, а я могу написать программу на ассемблере (любом менее более нормальном спековском ассемблере, думаю даже GENS прокатит), которая выводит надписть (правда фиксированную надпись и по фиксированным координатам) вообще без комманд LD!
По фиксированным неинтересно. Тогда уж хоть на бордюре ;)

ZEK

13.01.2011, 15:44

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

Lethargeek

13.01.2011, 15:45

и без самомодификации кода? ДАВАЙ!
Что плохого в модификации кода? Команды-то БЕЗОПАСНЫЕ :p

Sinus

13.01.2011, 15:50

думаю, что ты загнул:) фиксированный адрес-то загружать будешь...

неа, не загнул :)
если напишу - ставишь в плашке "AMIGAAAAHHHHHH" (несмотря на то, что писать я буду на спековском асме).

Lethargeek

13.01.2011, 15:52

неа, не загнул :)
если напишу - ставишь в плашке "AMIGAAAAHHHHHH" (несмотря на то, что писать я буду на спековском асме).
Соглашайся, psb, соглашайся! :v2_devil:

Sinus

13.01.2011, 15:56

По фиксированным неинтересно. Тогда уж хоть на бордюре ;)

на бордюре придётся пользоваться OUT*
могу так: не использую LD, не использую всякие читерские OUTI/OTDR
только старый добрый OUT (254),A

Wowik

13.01.2011, 15:56

думаю, что ты загнул:) фиксированный адрес-то загружать будешь...

Через ADD загрузит

Sinus

13.01.2011, 15:58

ADD/ADC и SUB/SBC не использую

Wowik

13.01.2011, 16:01

ADD/ADC и SUB/SBC не использую

OR XOR AND

Sinus

13.01.2011, 16:05

тоже без них. и вообще, хватит перечислять список комманд Z80.
если угадаешь, то интрига пропадёт :)

---------- Post added at 15:05 ---------- Previous post was at 15:02 ----------

Lethargeek, так что, надо на бордюре?

не буду использовать LD/ADD/ADC/SUB/SBC/XOR/AND/OR/OUTI/OUTD
придётся использовать OUT(254),A

если делаю - пишешь в плашке "BETA BASIC is better then assembler."

Wowik

13.01.2011, 16:06

тоже без них. и вообще, хватит перечислять список комманд Z80.
если угадаешь, то интрига пропадёт :)

стек на экранную область и цепочка Call :v2_dizzy_rastoman:

Sinus

13.01.2011, 16:08

стек на экранную область
LD SP,NN ? низзя

и вообще, придумай лучше свой метод, а не угадывай мой :)

psb

13.01.2011, 16:10

неа, не загнул
ненене, я уже понял:)
вариантов много.

Что плохого в модификации кода? Команды-то БЕЗОПАСНЫЕ
дурной тон. и нифига не безопасные, ошибся и коду ппц.

osa

13.01.2011, 16:10

Wowik, не гадай, я попкорн ищу....

Sinus

13.01.2011, 16:13

тем временем у меня на 100% оформилась первая абсолютно не читерская идея как вывести фиксированную надпись в фиксированном месте.

за подпись "AMIGAAAAAHHHHH rulez, ZX sux" (на две недели, причём надо как обычно писать на форуме, а не залазить в подполье) я отдам свою щикарную идею в массы.

кто готов?

psb

13.01.2011, 16:16

че бы мне тоже попросить за такую идею? я ж тоже могу:)

Sinus

13.01.2011, 16:19

вывести надпись не используя ни самомодификации кода, ни LD/ADD/....... ?
ах да, процедуры ПЗУ тоже не используя.

крут тогда :)

Lethargeek

13.01.2011, 16:23

Lethargeek, так что, надо на бордюре?

не буду использовать LD/ADD/ADC/SUB/SBC/XOR/AND/OR/OUTI/OUTD
придётся использовать OUT(254),A

если делаю - пишешь в плашке "BETA BASIC is better then assembler."
Ага, щяз... SCF, CCF, CPL, RLA, DAA, SET, RES, RLC (ix+),a
И потом, не я же утверждал, то там где-то без чего-то не обойтись :rolleyes:

---------- Post added at 16:23 ---------- Previous post was at 16:19 ----------

дурной тон
НИИ ПЕТ

и нифига не безопасные
Как же не безопасные? Адресация-то ПРЯМАЯ :D

ошибся и коду ппц.
Ну, исправил сразу же, проверяя в эмуле
И все, навек никаких ошибок
Адреса модифицируемых ячеек - КОНСТАНТЫ :v2_tong2:

psb

13.01.2011, 16:58

Как же не безопасные? Адресация-то ПРЯМАЯ
2 раза прямая адресация - уже не прямая. сэмулировал косвенную - молодец. только плохо.

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

Lethargeek

13.01.2011, 17:10

2 раза прямая адресация - уже не прямая
Ну и в бейсике, значит, не прямая

по твоей логике небезопасных вообще не бывает. отладил в эмуле и все безопасное на веки веков
Если ты про константы, то действительно :)
Или ты, проснувшись, первым делом лезешь в гугль
удостовериться, а равно ль по-прежнему число "пи" 3,14159265...
А то мало ли... :p

psb

13.01.2011, 17:39

Lethargeek, ты не понимаешь смысл безопасности кода, вот и всё.

Lethargeek

13.01.2011, 19:12

Смысла сфеерической безопасности в синклервакууме? :D
Чем опасна процедура, заведомо неспособная ничего испортить?

Barmaley_m

13.01.2011, 23:31

НИИ ПЕТ
Кто-то тут говорил о том, что будто бы ассемблер - это структурный язык. Ну-ну. Человеку, который еще не понял основных принципов программирования, предлагаем понять, как это программа может модифицировать сама себя?

Как же не безопасные? Адресация-то ПРЯМАЯ
Ты по сути не опроверг моего высказывания о том, что ассемблерные программы сложны в отладке из-за того, что вследствие ошибок может испортиться в неожиданном месте сама программа или ее данные. Начинаешь рассуждать здесь о частностях, пытаясь отвлечь дискуссию в сторону, потому что по главному тезису аргументов у тебя нет. Юлишь, пытаясь уклониться от признания, что наехал безосновательно. Я смотрю, тебе бы хоть весь мир вокруг перевернулся. Устроил из конструктивной дискуссии балаган. Истина для тебя ничто по сравнению с желанием победить в споре, т.к. я сомневаюсь, что тебе нужно объяснять нижеследующие элементарные вещи, которые ты скорее всего и так знаешь, но намеренно "забыл" учесть при написании своего сообщения.

Модифицирующийся код может превратить прямую адресацию в косвенную по сути. Последствия от ошибок в таком коде - те же или еще хуже, т.к. в программу не по ошибке, а даже преднамеренно вносятся изменения во времени ее выполнения. Современные тенденции в архитектуре вычислительных систем направлены на устранение возможности ошибочной или злонамеренной модификации программы путем помещения ее в ПЗУ или в область ОЗУ, защищенную от записи. Попутно, конечно, блокируется и возможность самоизменения программы в благих целях, но раз этим жертвуют, значит опыт научил, что такая жертва оправдана.

Ну, исправил сразу же, проверяя в эмуле
И все, навек никаких ошибок
"исправил сразу же" - это навроде печати сообщений одной командой CALL PRINT. Ты пытаешься сложные и трудоемкие вещи представить простыми.

goodboy

13.01.2011, 23:47

если интересно вот пример одной из ошибок - в одной достаточно известной игре в один прекрасный момент экран заполнялся всяким мусором. мне удалось найти ошибку в процедуре печати энергии.

A,(XXXX)
SRA A
SRA A

сможете понять чем чреват такой кусок ?

Sinus

14.01.2011, 00:33

goodboy, A,(XXXX) это LD A,(XXXX) ?
честно говоря кусок как кусок, я ж не знаю что там дальше с этим A делается.
может там

LD A,(#4000)
SRA A
SRA A
XOR A
OUT (#FE),A

:)

есть догадка что стоило бы использовать SRL вместо SRA, но это остаётся лишь догадкой, ибо я не знаю куда дальше это A идёт.

Лас

14.01.2011, 00:39

A,(XXXX)
SRA A
SRA A

сможете понять чем чреват такой кусок ?
Мне кажется, что показанный кусок кода чреват ничем .

goodboy

14.01.2011, 00:40

это LD A,(XXXX) ?
честно говоря кусок как кусок, я ж не знаю что там дальше с этим A делается
да ld a,(xxxx) - как я понял автор планировал деление на четыре, но оно не всегда получается. и состояние флагов перед процедурой тут не причём.

Barmaley_m

14.01.2011, 00:40

A,(XXXX)
SRA A
SRA A

сможете понять чем чреват такой кусок ?
Ну, арифметический сдвиг, с размножением последнего бита, чего многие не учитывают - может проблема в том, что команду SRA использовали вместо SRL, работая с беззнаковым числом. Энергия вроде не может быть отрицательной.

Sinus

14.01.2011, 00:45

как я понял автор планировал деление на четыре, но оно не всегда получается. и состояние флагов перед процедурой тут не причём.

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

RRCA : RRCA : AND #3F

оно и по байтам столько же, и по тактам на 1 быстрее

----

а вот если бы делал на бейсике, то написал бы

LET re=INT(e/4)

и усё :)

goodboy

14.01.2011, 00:48

арифметический сдвиг, с размножением последнего бита, чего многие не учитывают

вот-вот. мне пришлось переводить числа в двоичную систему что-бы понять как такое может получиться (ну не было справочников по командам под рукой).
7F-3F-1F
8F-C7-E3 - вот и полетела процедура

Sinus

14.01.2011, 01:25

Спят все... В общем нате вам мой супер крутой вывод надписи без LD/SUB/ADD/XOR/... и т.д.
использую только NOP и RST #38 :) (и небольшой подготовительный код, который устанавливает чёрный цвет бордеру)

ORG #57F9

L0 DEC A
JR NZ,L0
OUT (#FE),A
JR $

NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
RST #38
RST #38
NOP
NOP
NOP
NOP
RST #38
RST #38
RST #38
NOP
RST #38
RST #38
NOP
NOP
NOP
RST #38
NOP
NOP
NOP
RST #38
RST #38
NOP
RST #38
RST #38
RST #38
NOP
NOP
RST #38
NOP
NOP
NOP
RST #38
NOP
RST #38
NOP
NOP
NOP
NOP
RST #38
NOP
RST #38
NOP
RST #38
NOP
RST #38
NOP
RST #38
NOP
RST #38
NOP
RST #38
NOP
NOP
NOP
NOP
RST #38
NOP
NOP
RST #38
NOP
RST #38
NOP
NOP
NOP
RST #38
RST #38
NOP
NOP
NOP
NOP
RST #38
NOP
RST #38
NOP
RST #38
RST #38
NOP
NOP
RST #38
NOP
RST #38
NOP
RST #38
NOP
NOP
NOP
NOP
RST #38
NOP
NOP
RST #38
NOP
RST #38
NOP
NOP
RST #38
NOP
RST #38
NOP
NOP
NOP
NOP
RST #38
NOP
RST #38
NOP
RST #38
NOP
NOP
NOP
NOP
RST #38
NOP
NOP
NOP
RST #38
RST #38
NOP
NOP
RST #38
NOP
NOP
NOP
RST #38
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
RST #38
NOP
NOP
NOP
RST #38
NOP
NOP
NOP
RST #38
NOP
NOP
NOP
RST #38
NOP
NOP
RST #38
RST #38
RST #38
NOP
RST #38
NOP
RST #38
NOP
RST #38
NOP
NOP
RST #38
RST #38
RST #38
NOP
NOP
RST #38
NOP
RST #38
NOP
RST #38
NOP
RST #38
NOP
RST #38
NOP
RST #38
NOP
RST #38
NOP
RST #38
NOP
RST #38
NOP
RST #38
NOP
RST #38
NOP
RST #38
NOP
RST #38
NOP
NOP
RST #38
RST #38
NOP
NOP
NOP
RST #38
RST #38
RST #38
NOP
RST #38
RST #38
RST #38
NOP
RST #38
RST #38
RST #38
NOP
RST #38
RST #38
RST #38
NOP
RST #38
NOP
RST #38
NOP
RST #38
NOP
RST #38
NOP
RST #38
NOP
NOP
RST #38
NOP
NOP
NOP
NOP
RST #38
NOP
RST #38
NOP
RST #38
NOP
RST #38
NOP
RST #38
NOP
RST #38
NOP
RST #38
NOP
RST #38
NOP
RST #38
NOP
RST #38
NOP
RST #38
RST #38
RST #38
RST #38
RST #38
RST #38
NOP
RST #38
RST #38
RST #38
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
RST #38
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
RST #38
RST #38
NOP
RST #38
NOP
RST #38
NOP
RST #38
RST #38
RST #38
NOP
RST #38
RST #38
RST #38
NOP
RST #38
RST #38
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
RST #38
NOP
NOP
NOP
RST #38
NOP
RST #38
NOP
RST #38
NOP
RST #38
NOP
RST #38
RST #38
NOP
NOP
RST #38
NOP
RST #38
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
RST #38
NOP
NOP
NOP
NOP
RST #38
RST #38
NOP
RST #38
NOP
RST #38
NOP
RST #38
NOP
NOP
NOP
RST #38
RST #38
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
RST #38
RST #38
NOP
RST #38
RST #38
NOP
NOP
RST #38
NOP
RST #38
NOP
RST #38
RST #38
RST #38
NOP
RST #38
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
RST #38
NOP
RST #38
NOP
RST #38
RST #38
NOP
NOP
RST #38
NOP
RST #38
NOP
RST #38
RST #38
RST #38
NOP
NOP
NOP
NOP
RST #38
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
RST #38
RST #38
NOP
NOP
RST #38
NOP
RST #38
NOP
RST #38
NOP
RST #38
NOP
NOP
RST #38
NOP
NOP
NOP
NOP
NOP
RST #38
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
RST #38
NOP
RST #38
NOP
RST #38
RST #38
NOP
NOP
NOP
RST #38
RST #38
NOP
NOP
RST #38
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
RST #38
NOP
RST #38
NOP
RST #38
NOP
NOP
NOP
RST #38
RST #38
NOP
NOP
NOP
RST #38
NOP
NOP
NOP
NOP
NOP
RST #38
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP

Lethargeek

14.01.2011, 01:44

Кто-то тут говорил о том, что будто бы ассемблер - это структурный язык. Ну-ну
Что "ну-ну"? Что такого неструктурного в самомодифицирующемся коде?

Кто-то тут говорил о том, что будто бы ассемблер - это структурный язык. Ну-ну. Человеку, который еще не понял основных принципов программирования, предлагаем понять, как это программа может модифицировать сама себя?
А как любой человек каждодневно "модифицирует сам себя"? :rolleyes:

Ты по сути не опроверг моего высказывания о том, что ассемблерные программы сложны в отладке из-за того, что вследствие ошибок может испортиться в неожиданном месте сама программа или ее данные.
Ты по сути его не доказал :v2_tong2: Ну испортилась, и что?
Чем сложней отлаживать на эмуле испорченную по сравнению с неиспорченной?

Начинаешь рассуждать здесь о частностях, пытаясь отвлечь дискуссию в сторону, потому что по главному тезису аргументов у тебя нет. Юлишь, пытаясь уклониться от признания, что наехал безосновательно. Я смотрю, тебе бы хоть весь мир вокруг перевернулся. Устроил из конструктивной дискуссии балаган.
Начинаешь рассуждать о всяких левых косинусах и численных методах, уводя дискуссию в сторону, потому что по главному тезису аргументов у тебя нет. Юлишь, пытаясь уклониться от признания, что высосал проблему из пальца. Развел по конструктивному вопросу злостный офтоп.

Модифицирующийся код может превратить прямую адресацию в косвенную по сути. Последствия от ошибок в таком коде - те же или еще хуже, т.к. в программу не по ошибке, а даже преднамеренно вносятся изменения во времени ее выполнения.
Последствия от ошибок в таком коде - лишний запуск в эмуляторе
Да и то необязательно, адрес можно на ходу поправить при трассировке

Современные тенденции в архитектуре вычислительных систем направлены на устранение возможности ошибочной или злонамеренной модификации программы путем помещения ее в ПЗУ или в область ОЗУ, защищенную от записи. Попутно, конечно, блокируется и возможность самоизменения программы в благих целях, но раз этим жертвуют, значит опыт научил, что такая жертва оправдана.
ГДЕ "оправдана"? :v2_dizzy_facepalm:
На Спектруме для игрушек?
Или все же в "современных архитектурах"?
Может, перестанешь наконец офтопить в каждом посте?

исправил сразу же" - это навроде печати сообщений одной командой CALL PRINT. Ты пытаешься сложные и трудоемкие вещи представить простыми.
Ты пытаешься простенькие вещи представить сложными даже не задумавшись