Терзают смутные сомнения, что тут БК сам с собой разговаривает...
Вид для печати
Терзают смутные сомнения, что тут БК сам с собой разговаривает...
Возможности, в нем заложенные
Сразу-то нахрен?
Паскаль в очумелых ручках привыкших к бейсику вмиг перестает быть структурным без всяких GOTO :v2_laugh:
Стал уже давно
А сморозивший - прикроется высокопарными фразами :rolleyes:
Вот я и спрашиваю: ну при чем тут Спектрум? Внешние железки, чтобы что-то скомпилировать (а то и чтоб запустить)
Твой паскаль умеет компилировать полноценные программы для работы на обычном Спеке БЕЗ наворотов?
Впрочем, даже в этом случае лучше подыскать песюковый кросс-компилер
...и Спек в CP/M режиме переставал быть Спеком, что и требовалось доказать
Ту же самую? Нет, не перестало :D
*терпеливо* Да о том же, что ты очень сильно переоцениваешь
в отрыве от современности :v2_dizzy_grandfathe
И еще желательней - не на Спектруме
Fgsfds... это к чему вообще? Предлагаешь начинающим начинать с отладки сложных алгоритмов? :v2_wacko:
После бейсика очень многое кажется НЕМЫСЛИМЫМ :v2_laugh:
Отрицательному - это во-вторых :v2_tong2:
Не вали с больной головы на здоровую
Это ты здесь начал плакать о косинусах и высасывать из пальца мнимые мегатрудности
умникам следовало бы знать, что это не баг бейсика! это фича вообще, глобальная. этим не только калькуляторы страдают (а особенно примитивные!!!), это вообще везде такой "баг". учи математику, знаток:)
и да. будь добр, покажи-ка свои поделочки на асме для спека? посмотрим, как ты круто управляешься с асмом. а то балаболить-то мы все горазды.
Меня вообще удивляет, как можно шесть страниц "меряться сингулярностями" и "жонглировать какашками"?! Было произнесено много "громких" слов, перечисленна масса "доводов" в пользу "верного и единственного" подхода в програмировании. Из всего этого, полезного, для себя я не увидел. Извиняюсь за копипасту, но, по-существу..
Скрытый текст
процесс работы компьютера заключается в выполнении программы, то есть набора вполне определённых команд во вполне определённом порядке. Машинный вид команды, состоящий из нулей и единиц, указывает, какое именно действие должен выполнить центральный процессор. Значит, чтобы задать компьютеру последовательность действий, которые он должен выполнить, нужно задать последовательность двоичных кодов соответствующих команд. Программы в машинных кодах состоят из тысячи команд. Писать такие программы - занятие сложное и утомительное. Программист должен помнить комбинацию нулей и единиц двоичного кода каждой программы, а также двоичные коды адресов данных, используемых при её выполнении. Гораздо проще написать программу на каком-нибудь языке, более близком к естественному человеческому языку, а работу по переводу этой программы в машинные коды поручить компьютеру. Так возникли языки, предназначенные специально для написания программ, - языки программирования.
Имеется много различных языков программирования. Вообще-то для решения большинства задач можно использовать любой из них. Опытные программисты знают, какой язык лучше использовать для решения каждой конкретной задачи, так как каждый из языков имеет свои возможности, ориентацию на определённые типы задач, свой способ описания понятий и объектов, используемых при решении задач.
Всё множество языков программирования можно разделить на две группы: языки низкого уровня и языки высокого уровня.
К языкам низкого уровня относятся языки ассемблера (от англ. to assemble - собирать, компоновать). В языке ассемблера используются символьные обозначения команд, которые легко понятны и быстро запоминаются. Вместо последовательности двоичных кодов команд записываются их символьные обозначения, а вместо двоичных адресов данных, используемых при выполнении команды, - символьные имена этих данных, выбранные программистом. Иногда язык ассемблера называют мнемокодом или автокодом.
Большинство программистов пользуются для составления программ языками высокого уровня. Как и обычный человеческий язык, такой язык имеет свой алфавит - множество символов, используемых в языке. Из этих символов составляются так называемые ключевые слова языка. Каждое из ключевых слов выполняет свою функцию, так же как в привычном нам языке нам языке слова, составленные из букв алфавита данного языка, могут выполнять функции разных частей речи. Ключевые слова связываются друг с другом в предложения по определённым синтаксическим правилам языка. Каждое предложение определяет некоторую последовательность действий, которые должен выполнить компьютер.
Язык высокого уровня выполняет роль посредника между человеком и компьютером, позволяя человеку общаться с компьютером более привычным для человека способом. Часто такой язык помогает выбрать правильный метод решения задачи.
Перед тем как писать программу на языке высокого уровня, программист должен составить алгоритм решения задачи, то есть пошаговый план действий, который нужно выполнить для решения этой задачи. Поэтому языки, требующие предварительного составления алгоритма, часто называют алгоритмическими языками.[свернуть]
Каждый сам выбирает - строить ли ему "конуру из бетонных блоков" или "вырезать дом в скале"..
Бугога! Стало быть, явная ошибка в первом же знаке после запятой при расчетах с внутренним двоичным представлением вещественных чисел это "глобальная фича"? Математику здесь нужно явно учить тебе :v2_laugh:
Поищи по форуму, все лежит, что счел нужным выложить
Кстати, как насчет твоих поделок на синклер-бейсике?
Только не забудь убрать из них расово неверный инпут с инкеем :v2_devil:
А по существу - эмулятор плюс кросс-ассемблер это нынче сразу целый завод железобетонных конструкций с ультразвуковым контролем качества по сравнению с кустарными шлакоблоками синклер-бейсика. Кое-кто здесь до сих пор не может понять, что предмет дискуссии - преимущества и недостатки определенных средств разработки в определенное время, а не сферобейсики в синклервакууме.
Отвечаю, хоть и несколько запоздало (у вас тут дискуссия уже далеко зашла). По Вашим, Barmaley_m, ответам вижу полное непонимание написания программы на ассемблере. Все время проекция оного с метода написания на бейсике. Я ж написал, что принцип одинаков. Но нельзя понимать это буквально. Одинаков подход к написанию, но методы отладки и использования дополнительных процедур разные. Итак, по порядку:
Во первых, я не имел ввиду написание программы на асме в магнитофонном варианте, хотя и так я писал года до 1994-го. В Gens3 потом в 4-м. И ещё в Zeus. Сохранял на кассету текст перед компиляцией и запуском. Да. Думать приходилось сильнее, а не тут же жать на кнопку запуска. Я далее это поясню.
Совершенно несогласен. Во первых, в отладчиках (под которыми предполагается отлаживать программу которую мы пишем) есть режим эмуляции кода. Есть точки останова. Хотя я в 1992-1994гг ими не пользовался, а пользовался (как тут уже писали) монитором прошивки "турбо-90", вывел себе проводок от 17-й ноги Z80 и быстро проводил проводком по радиатору БП. Комп вылетал в монитор. Вот вам и прерывание. Да, иногда все напрочь висло (о этом случае я писал в Ревюшке'93), но это не смертельно. А вот с бейсиком беда. остановить его мы можем (хотя используя несложный прием мы это можем отключить), но как посмотреть состояние программы? Нужно проверять значения всех переменных (глобальных) вводя кучу команд... Сложнее чем в отладчике.
Вот тут вообще не понял. С моей т.з. в этом отношении и бейсик и асм одинаковы. Ведь как пишется программа? Мы продумываем структуру, блоки, их взаимосвязь, а потом уже начинаем реализовывать задуманное. Грубо говоря приводя программу к структурированному виду, когда вся программа это иерархическая система "черных ящиков". У каждого ящика есть вход и выход. Нам надо реализовать функционал, потом о реализации можно забыть. Важно что бы ящик делал то, что нам надо. Делаем "внутренности" раскладывая сложные алгоритмы в набор более простых, вернее пишется скорее всего наоборот (уже когда структура программы проработана) пишем сначала базовые процедурки, потом на их основе более сложные и т.д. В бейсике процесс написания абсолютно аналогичен. И в паскале также. Предвижу возражения, что дескать "мы так не писали, писали как получится". В том то и дело, что если делать так, то ничего серьезного не напишешь. Это обычная тактика новичков, кто учится программировать. Бейсик для этого и предназначен, но и на нем можно писать так как я описал выше.
Тут согласен, но отчасти. Разборщик выражений в бейсике логической ошибки в программе не увидит и будет сидеть начинающий проггер и тупить над программой, а ошибка может быть и в алгоритме вычислений и в логике, да где угодно. А в асме без библиотки арифметических функций делать нечего. Нужен набор процедур, или самописный (что лучше всего, сначала писать их, учить асм, учить команды проца) или чей-то. Здесь ещё хочу сказать, что нужны базовые знания по программированию, в области арифметики. Т.е. точное представление двоичной и шестнадцатеричных систем исчисление, представлять себе деление, вычитание, сравнение, умножение, деление чисел. Знать алгоритмы быстрого деления и умножения сдвигом. В бейсике это не нужно, но знать программисту это всё равно надо. Такое мое мнение.
Можно пользоваться подпрограммами ZX-Basic, или опять же иметь свои наработки. Это полезней со всех сторон. Необходимо понимать как работает машина. Начинающие писать на бейсике этого сознательно лишаются. Они изучают некую абстрактную бейсик-машину. Со своим экраном, клавой и памятью в виде переменных и массивов. С одной стороны в этом и был смысл бейсика, абстрагировать обучающихся от железа, что бы они учили процедурное программирование. Но в этом и грабли на будущее. Т.е. зацикливаться на чем то одном не надо. Пописал человек 2-3 месяца на бейсике, более-менее изучил его и надо двигаться далее. Изучать в первую очередь архитектуру машины, основы программирования на асме (то что я выше описывал) и примерно через полгода уже можно приступать к написанию первых процедур. И уже позднее программ. Т.е. смысл сказанного мной таков. Имея знания о архитектуре компа, имея опыт написания программ процесс написания на бейсике и на асме будет похож. Примерно как снимать очень дорогой камерой изменяя и контролируя несколько десятков параметров и телефоном, нажимая на одну кнопку. Получаем и соотв. результаты.
Нужно не только изучать сам бейсик или асм, а изучать программирование, архитектуры проца, конкретной машины, видоподсистемы. Представлять себе как можно реализовать алгоритмически аркадную игру (типа Exolon, R-Type, River Raid, Crazy Cars). Как написать движок. И уже потом можно браться за инструмент. Бейсик, Паскаль, Си или асм. Есть примеры игр совершенно другого плана, изометрия, 3D (Dark Side и прочие), адвентюры с графикой и без и т.д. И каждый тип имеет свой движок, свои особенности. Не зная их, не понимая даже при идеальном знании Паскаля или Си игру не напишешь. Поэтому вопрос заданный в теме мне не понятен. Вернее понятен, что автор некорректно поставил вопрос из-за не понимания вопросы программирования игр вообще.
А ещё хотелось бы сказать, что проблемы освоения асма, паксаля или Си возникали ранее у тех, кто начинал с бейсика из-за скомканности обучения всему что связано с компьютерами. То кидаются в сторону алгоритмов, то учим бейсик, то устройство компа обзорно. В этом проблема. Масса отрывочных сведений, мало связанных между собой. Человеку который видит это всё впервые сложно усвоить всю инфу и адекватно её воспринять. Однобокое, неполное понимание в дальнейшем создает проблемы. Некоторые люди в упор не воспринимают hex числа, при том пишут программы на асме. Вот вам привет из zx-бейсике (в других реализациях бейсика hex числа есть). Т.е. если изучать всё планомерно и последовательно, что из себя представляет компьютер и с чем его едят, то и проблем будет меньше.
бред несешь. разберись вот как раз с "внутренним двоичным представлением вещественных чисел".
мы разговариваем не по форуму, а конкретно в этой теме, выложи ссылки на свой софт. или ты слить решил по тихому?
забавно это читать:) тов. Barmaley_m более чем в адеквате:) и про асм знает не по наслышке:) просто рассуждает не только смотря на свой личный опыт.
вводя команды типа LIST, PRINT, ты нажимаешь несколько кнопок. для того чтобы в отладчике посмотреть содержимое памяти или код, ты точно так же нажимаешь несколько кнопок.
только вот досада: хочешь ты посмотреть переменные A,B,C и строку D$, в бейсике ты так и пишешь: PRINT A,B,C,D$ - получаешь значение переменных в остановленный момент. а что ты делаешь в асме? для начала тебе надо знать адрес твоих переменных. где ты его берешь? ищешь кусок кода с этим адресом? или наугад среди кучи данных (по т.н. eyecatcher), зная что вслед за чем лежит? или открываешь листинг асма и ищешь там свою переменную? не слишком ли???
далее, нашел ты переменную, 2 байта, а там D5 38. ЭТО СКОЛЬКО???
вы будете дальше настаивать на удобстве дебаггера??
и в этом кроется ошибка в ваших рассуждениях:) новичок так не делает никогда! он просто не умеет продумывать структуру, не понимает никаких черных ящиков. потому он и новичок. а теперь представь, что человек этого не умеет и переосознай:)
если человек си или паскалем хоть как-то вынужденно начинает программу структурировать, то в асме руки полностью развязаны и просто так он этого делать ни за что не будет. а в современных ЯВУ как раз идет тенденция связывания рук, чтобы нельзя было делать всё что в голову взбредет.
правильно! новичку их сначала тока надо где-то взять, потом РАЗОБРАТЬСЯ как их использовать (это для вас сейчас это просто!), а потом юзать.
а писать такое новичку - да большинство нахрен пошлет программирование сразу, т.к. результата не будет ну очень долгое время.
это ты хочешь предложить новичку?:))))) я подозреваю что этого даже монстр асма Lethargeek не знает... бейсик (и любой алгоритмический язык) тем и хорош, что ты заморачиваешься только с алгоритмом, но не с борьбой с машиной.
нехватку регистров в асме уже никто не помнит? память короткая?:) ах да, у Lethargeek особый ламерский метод складывать все в память...
нет здесь граблей. направления в программировании бывают разные и не стоит всех заставлять проходить свой путь. если ты системщик - тебе полезно знать то, о чем ты пишешь - алгоритмы деления, умножения, как работает комп. если же ты прикладник - в гробу видал все эти премудрости, твоя задача - решать поставленную задачу ЛЮБЫМИ методами. есть невероятное количество людей, никогда не изучавших асм, но делающих такие вещи, которые мы тут все вместе взятые можем не асилить. само по себе программирование - ничто и никому не нужно, оно становится значимым только в применении к какой-то области. и именно программированию учиться лучше точно не на асме. асм нынче вообще мало кому нужен.
вот здесь вряд ли бы кто стал спорить, все верно.
не соглашусь. пишут так потому что тупо привычка считать в десятичной системе. сложно обычному человеку вообще понимать другую систему.
если писать все на асме, максимально продумывая, то винда и все остальное будет просто летать, даже на древних компах! и не глючить! ибо писавший будет досконально знать что и как он сделал. хехе:) но в реальном мире - это УТОПИЯ! это не реально ни на 0.001%. просто жизни не хватит и людей.
Лол, с каким? С тем, в котором 1/2<>0.5? Уймись уже, балаболка!
Или мне тебе напомнить алгоритм деления в столбик для первоклашек? :v2_dizzy_facepalm:
Чтобы ты сумел поделить пятерку на десятку в двоичном коде
сосчитав на пальцах, сколько битов нужно для вычислений
Ты УЖЕ слил по-тихому, даже слова не сказав о своих поделках на бейсике :v2_dizzy_stop:
Лично я обычно нажимаю Step или Step Over и вижу все :cool:
Кстати, как на бейсике организовать обычную трассировку?
Или как следить за ходом прорисовки, не потеряв саму прорисовку?
Будешь дальше настаивать на удобстве отладки ручками под бейсиком?
Вот досада: хочешь посмотреть переменные в ЛЮБОЙ момент - и не можешь :v2_tong2:
Кинуть в калькулятор или просто кликнуть кнопочку decimal так трудно? :rolleyes:
Кстати, перед этим не мешает для начала определиться, нужно ли оно вообще в десятичном виде
Судя по его постам в других ветках я в курсе, но тут какие-то неуместные сравнения.
Если честно, то никогда глубоко не отлаживал своих программ. Всегда "отладку" делал в уме, смотря на текст программы. И уж если совсем затык (было пару раз) то уже пользуюсь отладчиком. А вообще переменные можно держать в одном месте. Да и для отладки конкретного участка не надо их смотреть десятками.
Это 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 назад. Так оно. Хоть все и не реально на асме написать, но побольше чем сейчас - вполне реально, а то сейчас даже драйверы для видях пишут на Си. И получаем кривоту кривейшую. Не раз уже встречал случаи когда производитель так и не избавлялся от фатальных ошибок, бросал продукт и начинал "новую версию".
Напоминаю, мы о спектруме говорим, а не о ПЦ.