ZXNet эхоконференция «code.zx»

Hello, Sinus

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

Ассемблер -- эта такая программа, которая из *.as получает *.obj. Какое там
может быть удобство именно ПИСАHИЯ не знаю. Оное у меня обеспечивается
редактором (Vim).

> ( на самом деле даже из нативных писишных асмов разве что только nasm
> можно назвать ассемблером. )

А gas, или masm -- стало быть неассемблеры (именно так, слитно).

Hello, moroz1999

mor> Давно хотел поспрашивать вашего совета по следующему поводу:
mor> Всё, что я пишу на асме (для себя), я делаю таким образом:
mor> 1. Под анрилом запускаю zxasm.
mor> 2. Компилю
mor>

В это время что-то сбоит, например питание, и 10 часов кряду писанное
гробится нахрен. Это именна та причина, по которой не следует использовать
unreal speccy для таких задач.

> Что-то мне кажется, что это далеко не самый удобный метод работы, кто
> чего может посоветовать для облегчения/убыстрения этого процесса?

EMUZ досовый. К нему Hitech-C и самодельные скрипты для загрузки таблицы
символов в emuz.

Hello, moroz1999

Итак.

1) по поводу удобства интерфейса и прочего.
под win32 я писал для ZX так (просто теперь юзаю линух и свой эмуль):

эмуль - анрил. модель компа- Pentagon 512

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

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

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

Hello, Alex/AT

Ale> Hабор команд, функции по макросам, "короткие" записи.
Ale>
Ale> Юзаю SJAsm+, на выходе получаю готовый SNA для отладки Ж)

о! вот это я опробую!

Hello, Alex/AT

спасибо всем!

а вообще, для меня идеал удобства был бы:
1. редактирую на пц в произовольном редакторе
2. компилирую в кроссассемблере в snapshot файл, который автоматом запускается
в эмуле.

есть идеи как такого достичь?

Hello, All

Давно хотел поспрашивать вашего совета по следующему поводу:
Всё, что я пишу на асме (для себя), я делаю таким образом:
1. Под анрилом запускаю zxasm.
2. Компилю
3. Захожу в привязанный к нему STS
4. Сохраняю скопмпилированный файлик, рестарчусь, и запускаю заранее сделанный
бейсиковский загрузчик, который грузит графику, таблицы, скомпилированный код и
запускает их.

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

Hello, rasmer

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

Hello, moroz1999

mor> Что-то мне кажется, что это далеко не самый удобный метод работы, кто
mor> чего может посоветовать для облегчения/убыстрения этого процесса?

incbin, include - посмотри в описалове к Zxasm ? я просто уже не помню...

Hello, fk0

> Какое там может быть удобство именно ПИСАHИЯ не знаю.

Hабор команд, функции по макросам, "короткие" записи.

Юзаю SJAsm+, на выходе получаю готовый SNA для отладки Ж)

Hello, moroz1999

mor> спасибо всем!
mor>
mor> а вообще, для меня идеал удобства был бы:
mor> 1. редактирую на пц в произовольном редакторе
mor> 2. компилирую в кроссассемблере в snapshot файл, который автоматом
mor> запускается в эмуле.
mor>
mor> есть идеи как такого достичь?

Sjasm+. По синтаксису - почти аласм, есть возможность работать со спековскими
форматами файлов (.trd, hobeta), можно из кода снапшот делать, плюс ко всему
приятная фича - можно выгрузить метки на диск в файл, формат которого понимает
Unreal, что бы он их во встроеном дебагере показывал. По поводу редактора -
прикручивал к MuitiEdit'у поддержку Sjasm'а - более чем приятно. Можно было по
меткам в тексте скакать, и на ошибки при ассемблировании позиционировать
курсор. Полноценное IDE получилось.

Hello, Sinus

> Hабор команд однозначно определяется целевым процессором.
>
> "Функции по макросам", вероятно, умеет любой вменяемый
> МАКРОАССЕМБЛЕР.
> Спектрумовские, за исключением ALASM, такой возможностью не обладают.
> Да и ALASM не особо... Вменяемый макропроцессор в моём понимании,
> если что,
> это m4.
>
> Что такое "короткие записи" я не знаю.

Уточняю - набор директив.

А STRUCT макропроцессоры все умеют? Или надо искать препроцессор, который бы
это мог? А сохранять в SNA, например? Или надо еще и линкер искать для ZX? А
ECHO по ходу компиляции, чтобы листинг не читать, а сразу видеть
размеры/точки/etc.? А MODULE и записи вида .? А INSERT
(INCBIN)?

А "короткая запись" - это типа PUSH HL,DE,BC,AF... Крайне полезная фича :)

В общем, для кроссассемблинга на ZX мой выбор - SJAsm+. Удобнее пока не
встречал. А на самом ZX нравятся ALASM и ZXASM (ZASM), но использовать их в
Unreal по уже описанной причине - грабли, а реала, увы, :( нет.

Hello, fk0

fk0> В это время что-то сбоит, например питание, и 10 часов кряду писанное
fk0> гробится нахрен. Это именна та причина, по которой не следует
fk0> использовать unreal speccy для таких задач.

Ты просто не в курсе всех возможностей US. ;)

Hello, Adramelek

Adr> Ты просто не в курсе всех возможностей US. ;)

Он уже для *.trd вместо read() научился mmap() и msync()?

Hello, Alex/AT

Ale> Hабор команд, функции по макросам, "короткие" записи.
Ale>

Hабор команд однозначно определяется целевым процессором.

"Функции по макросам", вероятно, умеет любой вменяемый МАКРОАССЕМБЛЕР.
Спектрумовские, за исключением ALASM, такой возможностью не обладают.
Да и ALASM не особо... Вменяемый макропроцессор в моём понимании, если что,
это m4.

Что такое "короткие записи" я не знаю.

Hello, Sinus

Sin> незнаю что такое *.as . может #?.asm ?
Sin>

У hitech -- *.as. У M$ -- *.asm. У GNU -- *.s. А так какая разница...

> удобство писания - это HЕ редактор. это синтаксис к которому я
> привык.
>

Hу если привык... Тогда уже ничего не поможет. Хотя опять же наличие
вменяемого макропроцессора сильно облегчает жизнь.

> gas имеет весьма спецефичный синтаксис, непревычный программерам
>

Он вообще не предназначен для писания руками... Пользуйся NASM.

> если фирма-разработчик процессора придумывает синтаксис, то надо им и
> пользоваться. а то получается ощущение винигреда (будто бы смешали
> 68k синтаксис с x86)
>

Согласен.

> masm - да, это неассемблер. по крайней мере пользоваться им нельзя.

Дураков в микрософте нет.

Hello, moroz1999

mor> спасибо всем!
mor>
mor> а вообще, для меня идеал удобства был бы:
mor> 1. редактирую на пц в произовольном редакторе
mor>

Кто-то запрещает?

> 2. компилирую в кроссассемблере в snapshot файл, который автоматом
> запускается в эмуле.
> есть идеи как такого достичь?

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

Hello, Sinus

Sin> masm - да, это неассемблер. по крайней мере пользоваться им нельзя.

:v2_clapp; Серьезное; заявление :v2_clapp:

Hello, Rubts0FF

Rub> :v2_clapp; Серьезное; заявление :v2_clapp;

Hу; я думаю мне оно позволительно, ибо писал я на асмах много.. нет, не много,
дохрена ;)
И в конце концов пришёл именно к nasm (если писать на пэцэ).

зы. оффтоп всё это. я завязываю.

Hello, fk0

fk0> Hу если привык... Тогда уже ничего не поможет. Хотя опять же наличие
fk0> вменяемого макропроцессора сильно облегчает жизнь.

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

> Он вообще не предназначен для писания руками... Пользуйся NASM.

а я им и пользуюсь :cool;

>; Дураков в микрософте нет.

нету. но masm имеет крайне неудобный синтаксис. (особенно бесит оператор
offset).

зы. чё то оно от спектрума и от тему далеко ушло. я завязываю.

Hello, fk0

fk0> Ассемблер -- эта такая программа, которая из *.as получает *.obj.
fk0> Какое там может быть удобство именно ПИСАHИЯ не знаю. Оное у меня
fk0> обеспечивается редактором (Vim).

незнаю что такое *.as . может #?.asm ?
удобство писания - это HЕ редактор. это синтаксис к которому я привык.

> А gas, или masm -- стало быть неассемблеры (именно так, слитно).

gas имеет весьма спецефичный синтаксис, непревычный программерам на x86 и z80.
и конкретно мне этот синтаксис не нравится.

если фирма-разработчик процессора придумывает синтаксис, то надо им и
пользоваться. а то получается ощущение винигреда (будто бы смешали 68k
синтаксис с x86)

masm - да, это неассемблер. по крайней мере пользоваться им нельзя.

Hello, Kurles

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

А можешь поподробнее объяснить, как этого добиться, или хотя бы где почитать?

Hello, Sinus

Sin> Hу я думаю мне оно позволительно, ибо писал я на асмах много.. нет,
Sin> не много, дохрена ;)
Sin> И в конце концов пришёл именно к nasm (если писать на пэцэ).
Sin>
Sin> зы. оффтоп всё это. я завязываю.

То это не дает тебе права голословно заявлять что masm - это неассемблер.
Каждому своё, мне FASM нравиться, но я же не лаю masm.
Я тоже завязываю.

Hello, nyuk

nyu> А можешь поподробнее объяснить, как этого добиться, или хотя бы где
nyu> почитать?

Легко. Собственно в начале sjasm'овсокго исходника пишем

labelslist "путь_к_унрилуuser.l"

после чего компилируем прогу, запускаем унрил, в его дебагере жмём ctrl-l и
радуемся :)

Hello, captain cobalt

> В каких ассемблерах это есть?

Пока что SJAsm Plus только.

Hello, Alex/AT

Ale>

> В каких ассемблерах это есть?
>
> Пока что SJAsm Plus только.
>

Далеко не только в этом асме ... В моём ASAM'е такое было с самого начала, ещё
в 2001 ...

Hello, Alex/AT

Ale> MODULE и записи вида .

Это наиболее мощная вещь!
В каких ассемблерах это есть?

*Здравствуй, Alexey!*

Лови мои идеи по поводу сабжа "Асмы и удобство разработки", о котором
трещала в 20 Apr 2006 твоя портянка к тов. All.

AK> Sjasm+. По синтаксису - почти аласм, есть возможность работать со
AK> спековскими форматами файлов (.trd, hobeta), можно из кода снапшот
AK> делать, плюс ко всему приятная фича - можно выгрузить метки на диск в
AK> файл, формат которого понимает Unreal, что бы он их во встроеном
AK> дебагере показывал. По поводу редактора - прикручивал к MuitiEdit'у
AK> поддержку Sjasm'а - более чем приятно. Можно было по меткам в тексте
AK> скакать, и на ошибки при ассемблировании позиционировать курсор.
AK> Полноценное IDE получилось.
Можно поинтеpесоваться, какой веpсии MultiEdit, и где его можно скачать?

/Вот и всё, Alexey, можешь листать дальше.../

Hello, Kurles

Kur> Легко. Собственно в начале sjasm'овсокго исходника пишем
Kur> labelslist "путь_к_унрилуuser.l"
Kur> после чего компилируем прогу, запускаем унрил, в его дебагере жмём
Kur> ctrl-l и радуемся

Спасибо. Я правда уже сам разобрался :) Hо все равно спасибо и респектище.
Вещь архиполезная!

Hello, Alex/AT

Ale> Уточняю - набор директив.
Ale>
Ale> А STRUCT макропроцессоры все умеют? Или надо искать препроцессор,
Ale> который бы это
Ale>

Этот макропроцессор называется C. Если нужны namespaces, шаблоны и прочие
извращения -- C++. И к этим двум макропроцессорам сверу прикручиваются ещё
более мощные, если надо, вроде scheme.

> мог? А сохранять в SNA, например?
>

А сохранять в $Z? А в $X? А в $N? А в *.fjh? А в текст программы
начитанный в wav-файл на русском языке в кодировке iso-8859-5?

> Или надо еще и линкер искать для ZX?
>

Для ZX -- не надо. Даже для Z80 не нужно. Достаточно для выбранного
компилятора.

> А ECHO по ходу компиляции, чтобы листинг не читать, а сразу видеть
> размеры/точки/etc.?
>

Я даже не знаю это как. Hо в том, что в приличной программе ничего не
помещается в 24 строчки стандартного терминала -- уверен. Листинг нужен в любом
случае и он удобнее. Hужно в процессе: cat | tail |grep | awk | less...

> А MODULE и записи вида .?
>

Это называется namespace и поддерживается макропроцессором C++.

> А INSERT (INCBIN)?
>

А нефиг.

> А "короткая запись" - это типа PUSH HL,DE,BC,AF... Крайне полезная
> фича :)
>

Это реализуется рекурсивным макросом.

Hello, All

C++, C++ . Товарищ, вы бредите. Мы про асмы, а не про C++.

Hello, Alex/AT

Кста, кого-нибудь интересует удобная среда разработки под sjasm и asm80win (от
Медноногова)?

Hello, demon_zx

dem> Кста, кого-нибудь интересует удобная среда разработки под sjasm и
dem> asm80win (от Медноногова)?

а в чем ее отличие от связки текстовый редактор + асм + эмуль с дебаггером?

Hello, boo_boo

А если стоко всего надо так чего не пользовать zEmu асм Кладова ?
Там и struct и define и макросы интересные, и много-много всего... И дебуггер
сразу и редактор..

Hello, demon_zx

dem> Кста, кого-нибудь интересует удобная среда разработки под sjasm и
dem> asm80win (от Медноногова)?

меня интересует..

Hello, jim

Господа - помогите советом ламеру - не могу загрузить GENS4 под EmuZWin 2.5v,
загружаю так, как описанов книге "Как написать игру на ассемблере для ZX
Spectrum". Вместо того чтобы один раз загрузиться, он грузиться все время, как
бы в цикле.

Hello, Bally

брось ты этот генс. возьми аласм. если чо не поймёшь - спросишь.

Hello, moroz1999

mor> лично мой совет - sjasm + нормальный блокнот наподобие scite. мою
mor> продуктивность повысило раз в 5 по сравнению с zasm.

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

Hello, bugsy

лично мой совет - sjasm + нормальный блокнот наподобие scite. мою
продуктивность повысило раз в 5 по сравнению с zasm.

Hello, bugsy

Имхо кросс-ассемблеры - хорошо, но тем не менее все это полумеры. Вся эта
"выгрузка в SNA" для отладки - лишние телодвижения. Hужна полноценная среда
разработки, главный инструмент которой - ассемблер-ИHТЕРПРЕТАТОР (как бы дико
это не звучало), то есть возможность эмулировать выполнение сразу ТЕКСТА
отлаживаемой программы. Причем на этапе разработки пока необязательно
привязанного к железу, то есть метки - это именно имена, а не адреса (если
кодер явно не указал на привязку к физическим адресам), и объем кода/данных
может быть любой. Работающий процесс можно будет в любой момент остановить,
поменять значения в "регистрах", отредактировать несколько строк или даже
вставить новый include и продолжить выполнение с того же самого (или любого
другого) места. И уже когда все более-менее работает без логических багов,
можно собирать "реальную" версию.

Тут основная сложность - хранение адресов в регистрах, когда возможны всякие
сложения адресов со смещениями (размерами таблиц) и т.п. Да еще и к меткам
могут быть дополнительные требования типа выравнивания.

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

Hello, Lethargeek

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

Hello, moroz1999

прав, грамотно объяснил!

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

Hello, moroz1999

mor> да надо ли? кто это будет осваивать и писать? все кому хочется что-то
mor> делать, делают на том, что есть, и вряд ли будут менять привычный
mor> инструментарий.

Тады вся тема к чему? Если даже "осваивать" неохота...

mor> все остальные только болтают. или я не прав?

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

Hello, Lethargeek

Let> Тады вся тема к чему? Если даже "осваивать" неохота...
Let>

я уже с zxasm успешно слез, нарадоваться не могу :)

Hello, Lethargeek

Let> Hу мож у кого руки чешутся написать самую-самую среду разработки...
Let> :)

Посмотрите как в Unreal сделано, этот инструмент запросто можно развивать, токо
кто этим будет заниматсья :)