Будущего нет у процедурного программирования. Скоро будут процессоры с 1024 ядрами, под которые можно писать только на функциональных языках или на чём-то, что ещё не придумали. Или вообще откажутся от понятия "ядро" и будут программировать на верилоге.Цитата:
Сообщение от Andrew771
alone, да да будущего нет :) доживем до декабря 2012 и посмотрим
Пардон, это же сложение? А я и писал именно про то, что сложения быстрей сдвига. Для байтов - add a,a - 4 такта, sla a - 8 тактов.Цитата:
Сообщение от jerri
Если нет разницы, то зачем платить больше?
вместо sla a лучше rlca.Цитата:
Сообщение от Eltaron
Eltaron, а чем тебе add hl,hl не сдвиг влево? :)
Для именно Спека я не пишу ничего.Цитата:
Сообщение от jerri
Для Ориона пишу и на асме и на С. Большая ли разница в писании под Орион и Спек - вопрос религиозный. Портирование стека TCPIP из исходников на С у меня заняло примерно 40 часов (месяц вечерами). Напишешь ты за 40 часов сетевой стек на ассемблере? Можно не отвечать, вопрос риторический.
С другой стороны, CP/M я правлю на асме, (хотя оригинал был на PL, кстати), и это очень долгий процесс - на асме проще наделать ошибок и сложнее отлаживаться.
Я конечно понимаю, что собственные шишки набивать, заново доказывая в 21 веке то, что уже считалось доказанным в 20м, это очень по спектрумистски, но тут уж давайте определяться: шашечки вам или ехать. Если дороже бесконечный и безрезультативный процесс, то пожалуйста - асм вам в руки. Если надо поиметь что-то реальное на выходе, то наиболее прямой путь - портирование. А с какого языка в код Z80 реально портировать, учитывая что на аcме Z80 ничего что нам хотелось бы, добрый дядя не выложил? Вопрос опять риторический.
ладно, уговорил :) действительно, этот машинный код можно было б и SLA HL назватьЦитата:
Сообщение от jerri
---------- Post added at 15:51 ---------- Previous post was at 15:48 ----------
но там же в случае переполнения ерунда получится, а не умножение?Цитата:
Сообщение от Andrew771
Если a<128, то нормально. Если a>=128, то и при sla a, и при rlca ерунда, т.к. результат уже двухбайтный должен быть (если использовать в ЯВУ).Цитата:
Сообщение от Eltaron
Неа, пользователями этого языка, вероятнее всего, будешь только ты один. Я тут такую привлекательную картинку нарисовал: программь под что угодно на чём угодно, и то подавляющее большинство оппонентов против, а не за. Чего уж сказать про Паскаль. Кроме того, человек, который не знает асма Z80, вероятно, не будет писать игры для Спектрума ни на чём. И я предлагаю знатокам асма не замену асму, а просто способ увеличить собственную производительность там, где это можно без потерь (или с малыми).Цитата:
Сообщение от Andrew771
Андрей, но ведь запись X*2+X это реверанс в сторону тупого компилятора, а запись X*3, которая, кстати, нагляднее для понимания (и проще), но которую умный компилятор может перевести в сложения и сдвиги, что, кстати, SDCC делает. Что подтверждает и Eltaron:Цитата:
Если, к примеру, X нужно умножить на 3, то я пишу на асме X*2+X, а не использую специальную процедуру умножения на произвольное число
Цитата:
Сообщение от Eltaron
Есть такая библиотека KOL, Владимир Кладов написал. Так она уже занимает больше мега исходников. Туда можно очень много добавить. Но программы, которые делаются на этой библиотеке, преимущественно размером < 100 Кб. Это очень реальный даже для Спека размер. Всё дело в подходе, потому как из KOL берётся только то, что используется. Примерно также можно сделать и с универсальностью. Да, у Спека экран устроен иначе, но в некоторых случаях для универсальности этим можно пренебречь. И пренебрегают, отсюда клэшинг атрибутов. Или ч/б вместо цвета. Всё можно продумать и сделать. Но очень трудно найти хотя бы 2 человека, которым на 100% понравятся все твои (или мои) идеи. Проблему я вижу именно в этом. А не в чрезмерной универсальности. Ну вот, спрайты Даша прекрасно себе чёрно-белые на Спеке и цветные под досом. Логика игры этот факт игнорирует, оставляя реализацию графической подсистеме. Разрешение экрана устройства она тоже игнорирует, манипулируя разрешением лабиринта. И так далее.Цитата:
Универсальность языка ведет к потере быстродействия и памяти. Для PC это не важно, т.к. там и того, и другого выше крыши. А для Спектрума это существенно. И тут нужно всё подгонять под него.
Я разве где-то предлагал такое делать? Всякому овощу свой сезон, а всякой задаче свой язык.Цитата:
А писать процедуру вывода спрайтов на ЯВУ они не будут - это неработоспособно.
Ладно, давай искать точки соприкосновения дальше. Ты собираешься реализовывать ReadLn для строк и чисел? Если да, любопытно было бы взглянуть. Я сделал такую процедуру ещё на языке Coloss, и она позволяла редактировать введённое число только полным затиранием и перенабором, сейчас полагаю, это надо исправить. Нервы юзеров дороже. Нужно обязательно реализовать забивку (Backspace), курсор влево-вправо. Ещё есть идея реализовать память для прошлых введённых значений (вдруг новое число проще получить из старого путём изменения одной цифры) по клавишам вверх-вниз (примерно как было в досовской проге Doskey, очень удобно). Функционал буфера прошлых введённых значений можно сделать опциональным (нетрудно придумать задачу, где он не нужен). Согласен или предпочитаешь что-либо попроще (или другое)?