DEB - ассемлер нового поколения...

Цитата:

---

Сообщение от Shadow Maker

ASMAN, и сделай пожалста то, чего уж точно нет ни у одного конкурента. Возможность алиасов любых команд. Например мне не нравится что подгрузка идет командой "INCLUDE" к примеру, хочу "ZAGRUZ". Взял, в файле алиасов поправил - и порядок! Или так INC меня не устраивает, хочу PLUS. Та же ботва. Будет очень удобно. Но надо обязательно тогда предусмотреть функцию по обратной конвертации исходников в нормальный неалисированный вид (чтобы можно было другим людям тоже сорцы читать).

---

Идея СУПЕР! Подумаю как можно классно и удобно енто организовать! Спасибо! ;)

Вот так люди! Берите пример с Shadow Maker'а ! Чем больше идей, тем круче будет редактор! :cool:

Цитата:

---

Сообщение от acidrain

Вот читаю все (весь тред) это и думаю, а нафига вам вообще нужны эти сокращения и весь этот выпендреж? На спектруме ничего не меняется, как делалось куча подобных и наполовину бесполезных прог, так и делается. Хотя, наверное, ни одна другая платформа не может похвастаться таким количеством асмов. =)
Cut, copy paste; ползунок (местоположение) - это единственные вещи, которые могут быть полезными. Вы сами себе усложняете жизнь, заставляя себя и других переучиваться с каждым выпуском компилятора. Правильно тут отмечалось, сделайте модульный асм - т.е. компилятор отдельно, редактор отдельно. Не выдумывайте никаких других (заменителей или как у вас модно алиасы) фич. С таким багажом ЗНАНИЙ , как на спеки уже давным-давно пора клепать более серьезные вещи. А то только и встречаю, что мол у него такой иходник, что без поллитры не обойтись =). Это глупо, вы не думали, почему линукс так быстро развивается? Потому что у них есть стандарт, который любой им заинтресованный знает.
Поверьте, если я снова вернусь кодить на спек, то не буду искать альтернативы моему некогда любимому xas'у. =)

---

Вот именно, что серьезные вещи толком и не наклипаешь без хорошего асма! :( А на счет альтернативы я не спорю, но все таки надо делать лучшее! ;)

Цитата:

---

Сообщение от ASMAN

Вот такой я! Это мой недостаток... :(

---

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

пока есть только скриншот и обещания :( обидно.

а свои недостатки надо стараться исправлять :)

Цитата:

---

Сообщение от elf/2

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

пока есть только скриншот и обещания :( обидно.

а свои недостатки надо стараться исправлять :)

---

ОК! На днях напишу все возможности DEB... При появлении (придумывании) новых идей эти возможности буду обновлять... :)

Низкий поклон, Всем !

Давно читаю эту рубрику и не очень понимаю что значит "нового поколения" ? Это асм занимающий в памяти НОЛЬ байт ???

Сколько помню себя, для меня в асме были главные два пункта 1.Качество компиляции, 2.Скорость компиляции ! Поэтому я давно колебался между TASM'омо и ALASM'ом, но когда узнал, что в аласме из-за однопроходности получается множество проблем, так и остался в TASM'е ... А вообще-то, всё, что мы делали с ребятами, так это просто переделывали TASM на 512 и компилировали любых размеров файлы ... Мне кажется, что стоит на этом поставить акцент ... Поскольку каждый из нас пишет под 128, и если у него отобрать хотя бы одну страничку, то будет много расстройств. А фреймовый скрол, конечно, велеколепная вещь, но только не в ущерб памяти.

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

Извеняюсь а свои пять копеек ... Но всё же память на Speccy, это драгоценная вещь, а особенно когда ебе 70 =) шутка ...

Цитата:

---

Сообщение от Robus

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

---

В Шторм-асме приблизительно так и делается. Оболочка каждый раз передекрюнчивается.

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

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

p.s. если кто-то хочет написать отдельный компилятор - вперед. У вас есть ACEdit и система плугинов к нему :)

гггг, класс!!! плагин-компилятор для АСЕ :))))

Цитата:

---

Сообщение от ASMAN

ОК! На днях напишу все возможности DEB... При появлении (придумывании) новых идей эти возможности буду обновлять... :)

---

ну наконец-то :)
тогда по мотивам поста breeze'а на тему проектов:
1. файл проекта это обычный текстовый файл (а почему нет) который содержит:
a. список всех исходников использующихся при сборке с указанием в какую страницу чего грузить + текущая строка/символ
b. настройки оболочки специфичные для данного продукта, например: сколько памяти отдать под метки, клавиатурные макросы, etc
2. при загрузке этого файла в асм, файл парсится и все файлы из 1.a загружаются куда надо + оболочка/асм настраиваются в соответствии с 1.b
3. ясен пень что в любой момент можно сохранить текущее состояние оболочки/асма в виде того самого файла проекта.
4. в принципе там же можно хранить всякие текстовые файлы типи readme, what's new, todo (при условии что редактор достаточно универсальный)

Цитата:

---

Сообщение от Looker

Нужен токенизированый вид, и чем жестче, тем лучше. А соответсвенно и редактор/вьювер злобно закодированных данных нужен исключительно индивидуальный!

---

1. суровый токенизированный формат плох тем, что в случае сбоя на диске легко потерять большую часть исходника. у меня была пара стормовых исходников с ошибкой в одном байте, при просмотре которых сторм падал, а bestView/xLook показывали достаточно большой кусок мусора...
2. а почему AlCo собирает достаточно большие проекты (Wolf2004) и не наступает на грабли с недостатком памяти? у alasm'а формат совсем не сурово-токенизированный...
3. еще есть большие сомнения что формат используемый в сторме положительно влияет на скорость компиляции

если есть правильные функи: decode_line/encode_line то редактор может быть достаточно универсальный

Цитата:

---

Сообщение от elf/2

ну наконец-то :)
тогда по мотивам поста breeze'а на тему проектов:

---

полностью поддерживаю! именно вот это я и имел ввиду! :eek: