Как стать автором
Обновить

Комментарии 74

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

P.S. Минусы под статьями — восстание роботов? :)
да не, я не напрягаюсь, я же 10 статей уже написал (типа «плавал, знаю» :-) )… всегда есть тот кто пишет на Си и всегда выскажется по поводу программированию на ассемблере… Причем не читая и не задумываясь :-))
мне вот если не интересно я и не минусую, но видать есть те кто по другому не может :-))
Кому-то не жалко заряда на минусование статей, которые они не читают.
Может дело в IDE Keil (у них платно) и EmBitz (бесплатно). А минусы как реакция на «негде».
а в EmBitz разве на асме писать можно? вроде как под Си заточена…?
EmBitz какой то не очень живой. Автор уже почти год молчит. Вроде бы где то было упоминание, что его попросили прекратить разработку и он согласился, но подробностей уже не помню.
НЛО прилетело и опубликовало эту надпись здесь
Не нужно пробовать г… но на вкус, что бы понять, что это г… но, как тот заяц в бородатом анекдоте.

Программировать нужно в VIM, все остальное от лукавого!
Ниже в комментах есть поклонник emacs, драка будет?
TL;DR :)
Тупой вопрос: модуль/плагин для того же VSCode/Atom (whatever) настолько занудно писать, что проще свой редактор сделать, или есть непереносимость электроноподобных редакторов?

(или отпугнула недостаточная гибкость таковых?)
1. Не знаю о чем вы говорите
2. программирование на асме имеет некоторые гм… особенности…
то есть писать придется скорее всего не один плагин… и не два… и боюсь что и не три…
то что реализовано сейчас — это как верхушка айсберга. то что можно делать и руками с той же степенью эффективности, но список хотелок (которые буду делать) намного больше… так что проще писать свое чем подстраиваться под другой продукт десятком плагинов (еще не зная что можно реализовать плагином, а что нет...)
ARM assembly highlighting for Visual Studio Code
и что там от редактора? подсветка кода ?!
и судя по подсветке addnes — правильно не работает…
Внезапно там VS Code в качестве редактора :) С соответствующими плагинами оно даже для отладки годится, live variables, memory view, svd-файлы и все такое…

Если подсветка не устраивает — ее же поправить можно, разве нет?
Так Вы бы и раскрыли тему этих особенностей, показали бы другим в чем причина острой необходимости создавать новый текстовый редактор.

Я сам пишу много кода для STM32 на Си со вставками ассемблерного кода. Считаю такой подход наиболее оптимальным. Писать вчистую на ассемблере имеет смысл только из академического интереса.

Вижу какую-то фигню+сниппеты. Вот бы заменить какую-то фигню на хоть какой-нибудь редактор… Нет, серьёзно....

ну так это же начало…

фигню бы с радостью на редактор поменял… но на какой? тем более что будут не только сниппеты
VS Code? :)

А какие вы уже рассматривали, и почему отбросили?

Emacs? (-:
Основной вопрос такой — а вам действительно нужно в 2019 году писать на ассемблере под достаточно мощный и быстрый STM32, вместо того, чтобы писать на С и С++? Т.е. есть какие-то задачи, где С/C++ не подходит? Если так, то не могли бы вы немножко рассказать о своих задачах?

Или вам просто хочется/нравится писать на ассемблере? Если так, то вопросов более не имею :)

Хотя бы для того, что бы узнать как устроено то, под чего пишеться на C )

Мне кажется, это можно понять и не программируя на ассемблере самостоятельно :) Например, читать дизассемблерный листинг, который любая IDE для С умеет показывать. Конечно, этот листинг сильно отличается от рукописаного кода на асме, но если все же программировать на С, то навык чтения этого листинга оказывается достаточно полезен сам по себе.

Это я все к тому, что даже с самым божественно-крутым редактором для ассемблера, писать на С все равно проще и легче; а если очень хочется, то можно ассемблерную вставку сделать.
ну читать листинг ассемблера arm боюсь далеко не каждый сможет и после годов в СИ
На мой взгляд, читать листинг проще, чем самому писать на ассемблере, а пригождается чаще.
Зарегистрировался чтобы ответить. Иногда действительно нужно. Достаточно быстрые STM32 (да и любые другие ARM контроллеры) все же не DSP, и если нужна нетривиальная обработка сигналов (что не такое уж редкое явление), то производительности уже впритык. Использование ассемблера позволяет раскрыть все возможности архитектуры.

Кто-то может затянуть известную песню про то, что современные компиляторы умные, они сами всё оптимизируют, лучше тебя, бросай ты это дело. Ничего подобного! Компиляторы тупы как пробка. Как то мне понадобилось синус вычислить. В начале вычисления возникал некий признак, который использовался в самом конце. Соответственно его нужно было где-то хранить. Я его засунул во флаг переноса, причем мне это ничего не стоило: попадал он туда как побочный эффект операции битового сдвига, лежал там тихонько, и в самом конце использовался посредством условной инструкции. Компилятор никогда бы до такого не додумался, выделил бы место где-нибудь на стеке (потому что свободных регистров не осталось). Это бы увеличило время выполнения функции процентов на 20 наверное. Вот такие вот дела.

Конечно это не значит, что приходится постоянно использовать ассемблер, нет. Просто ты используешь разные математические библиотеки, а вот они уже написаны на ассемблере. У TI, например, что fixed-point библиотека, что motor control, написаны как раз на нем.
Ну, я же не говорю, что никогда вообще не нужно на ассемблере писать, порой и правда приходится. Вот только мне кажется, что это происходит настолько редко, что ради этого писать свой редактор — это очень сильно перебор. Мне вот, натурально, это требовалось раза 3-4 за всю жизнь, причем и тогда можно было выехать на интрисинках компилятора, просто я об этом еще не знал.

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

Но вот синус мы уже считаем на этапе компиляции :)

Первый вопрос сразу — а на чем пишется редактор?
И второй — а рассматривался вариант взять готовое, например notepad++ и допилить плагинами? Тем более, у него исходный код открытый...

Судя по значку Лазаруса — на паскале.
Да и у EmBitz код открытый… И «допиливать» меньше прийдется. В EmBitz не мешало бы интегрировать загрузчики от STM (консольный Flash loader и loader из состава ST-Link)… Писан на wxWidgets, так, что теоретически кросс-платформенный.
www.embitz.org/svn/listing.php?repname=EmBitz
в тексте же написано — лазарус
Мне интересно как ретрограду пишущему на ассемблере — вы думаете уже статистически нормально считать архитектуру Win-ПК по умолчанию как x86_64?
расшифруйте свои пожелания… а то я не понял что нужно…

тем более это же демка, разработка продолжается…
Ну как минимум написать, что у значительной части аудитории эта демка работать не будет, чтоб зря не качали…
понял о чем вы, уже переставил среду… чуть позже буду выкладывать проект — будет в win32…
Почему yandex, почему на git не ведете? Может быть кто и подключился с помощью…

Как по мне, asm не совсем то на чем можно писать что-то большое (стоящее)
Драйвер работы с дисплеем, меню с 2-мя десятками подпрограмм. Каждая из которых переконфигурирует не только пины, но и NVIC и DMA…
Это слегка не тот инструмент для борьбы со сложностью…
P.S. лет эдак 7-8 один знакомый собирался прошивку писать для универских часов(с календарем и расписанием пар, дисплей 32×100 точек) на asm… короче не поднял…
года 2 назад похожий проект собирали другие студенты на Ардуине месяца за 4… оставив только дисплей…
ну не знаю… я как то писал программу управления радиоуправляемыми моделями на асме… правда там был авр…

у меня есть задача где мне 168 мгц такта на stm32f4 на асме по расчетом хватит в притык :-(( но я пока не хочу о ней говорить…
Бог с ним, с ассемблером. Нужно так нужно.

Но вот писать свой редактор? «Для ассемблера»? С нуля? Странный. Странный выбор…

PS: Ну возьмите хотя бы уже готовый и накидайте того, чего не хватает. Тот же QtCreator. Нарисуйте к нему свой плагин с синтаксисом и прочим и будет счастье. Опять же — людям польза. Вот это вот все никто в трезвом уме даже запускать не будет. Лениво т.к. результат очевиден. А вот плагинчик под уже обсосанной вдоль и поперек IDE включить — это вполне себе пожалуйста.
Qt это — RAD…
QtCreator — это среда разработки. К RAD он имеет опосредованное отношение. Да, в него встроен Designer (опять же как плагин) в котором можно рисовать Qt-шные формочки. Собственно на этом RAD заканчивается. В остальном и в основном это хорошо продуманный комбайн в т.ч. редактор кода с возможностью расширения.

Ну да бог с ним с креатором. Дело вкуса. Возьмите любой другой приличный редактор и расширьте его. Зачем тратить драгоценное время на бессмысленный мартышкин труд пытаясь реализовать то, что другие уже десять раз сделали по-определению лучше на порядок :-?
На всякий случай, есть еще FASMARM, добавка для FASM.
И да, EmBitz работает с Ассемблером, (я, например, подключил aarch64-linux-gnu для работы с 64 битной архитектурой, RPI 3 B+,A+). Для «голого железа» без Ассемблера не попишешь.
Кстати, FASMARM транслирует некоторые команды в код, для которых в GNU надо 2-3 команды вставлять или машинный код.
image
Картинка для FASMARM в текст не вставляется, вот её ссылка:
physicalcomputing.ru/images/Em2.jpg
(почему нельзя выбрать изображение на компьютере, а надо его в сеть сначала выгружать, да ещё и не вставляется?)…
Больше не буду тратить время на Хабро-комментарии.
image

посмотрел FASMARM — ну я конечно понимаю что мы сравниваем все бачки унитазов которые смогли найти… но там просто редактор…

на счет emBlitz ничего не буду писать, не использовал сам, по скриншотам неплохо, но я пишу для того чтобы максимально автоматизировать процесс…
сейчас вот закончил мастер поиска и вставки констант — я не знаю может конечно это где то реализовано (не в виде ручного поиска по инклудам) — пока не видел…
буду потихоньку писать ту функциональность которую сам использую, и посмотрим что получиться…
CP1251, KOI-8

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

всем и везде хватает
В эмбеде эта дикость используется для вывода на символьный дисплей, например. Тут или городить костыли обёртки в коде, или использовать однобайтные кодировки.
Многие, если не все, IDE это позволяют.
Или делать конвертацию в процессе сборки. Я бы сделал именно так, но специалистам, конечно, виднее, как им удобнее работать.
Ну дикость или нет, а когда сталкиваешься с файлами в другой кодировке, то приходиться «выплясывать»… так что проще иметь этот инструмент, чем придумывать каждый раз костыли для решения
Я дико извиняюсь, ценю душевный порыв автора. Настолько что даже восстановил пароль.
Во-первых интересует roadmap.
Скажите, а вы отдаете себе отчет в том что в итоге придется реализовать?
Т.е. как минимум, чтобы не быть просто блокнотом, нужно хотя бы прикрутить туда компилятор, дебаггер и флэшер, это не говоря уже о парсинге, подсветке, авто-дополнении и каком-то маломальском статическом анализаторе. А там еще веселее будет когда пойдет HAL для всего зоопарка решений от STM (хотя бы), CMCIS… Особенно имея опыт работы с самой STM как подрядчик. У самой STM их софт и некоторые аппаратные решения не работают как нужно. У меня уже дергается глаз, шевелятся волосы в бороде и свитер нервно скукоживается.
Ну каких то планов по срокам не существует…
а по задачам — в прошлых статьях я писал что хотелось бы иметь в редакторе…

На счет прикрутить «компилятор» — это не сложно
На счет дебаггера — еще не знаю, буду искать
прошивка по DFU в планах
на счет парсинга — был проект который парсил строки, причем парсил именно команды ассемблера, а не делал тупую подсветку без разбора написанного… так что тоже в планах…
а вот с подсветкой пока ничего не получилось… RichEdit очень тормозно работает (или я так и не смог с ним совладать), а другие варианты (например те которые есть в Lazarus) — несмотря на казалось бы имеющуюся функциональность — не подходят…
авто-дополнение — в планах
что такое статический анализатор не знаю :-( расскажите — подумаю
HAL запланирован, правда в виде модулей с возможностью визуальной настройки…

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

Сюдя я выложил одну из первых демок именно из попытки найти единомышленников и помощников…

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

Гм… смелое заявление, смелое.


В качестве примера, вот вам экстеншен для VSCode. Полагаю, это вас как-то вдохновит пересмотреть свою точку зрения.

спасибо за ссылку, посмотрю…

тем не менее, я пишу в первую очередь для себя.
это не моя профессия, и не способ заработать денег…
я пишу тот инструмент который мне нужен…
если он заинтересует кого то еще — с радостью поделюсь или приму помощь, если же Великий_all решит что есть более удобные инструменты — ну что же, я не буду никоим способом оспаривать чужой выбор…
Отладка конечно классно отображается… ничего не сказать…
интересно для ARM есть такой эмулятор? у амиги FS_AUE…
отладкой позже займусь, сейчас есть текущие задачи…

а вот с редактором с цветовыми схемами — я не нашел компонентов которые могли бы сделать то что я хочу, я тут некоторое время назад писал статью о попытках сделать на RichEdit — у меня анализировалась строка с коммандой ассемблера, и сразу проверялись параметры команды… но как заставить RichEdit работать быстро на больших файлах я не понял… на файле в 3000 строк тормоза были такие что о работе говорить не приходилось :-(
если интересно вот ссылка на демку yadi.sk/d/f8oMujxVqBiMz просто откройте файл из SampleCode, например main.asm и попробуйте что то добавить или убавить… — вот такое редактирование файла я хотел сделать, чтобы сразу получать ошибку если команда не верна или метки нет или еще что то не так… на глюки и недоработки в остальном не смотрите, я не смог победить объем поэтому завершил разработку на этот компоненте

свой редактор тоже пробовал писать (на базе TImage) -но мне не хватает быстродействия, видать должен быть другой подход для вывода текста… — пока есть только идея как переписать, чуть позже займусь (у меня в редакторе используется ТМемо, так что заменить один компонент на другой много времени не займет)
Если комфортно писать именно на паскале, то почему бы не покопать сам Lazarus, как они там сделали.
(Брать его самого за основу, наверное, не спортивно.)
может быть так и сделаю.
Сейчас задача минимум запустить редактор.
Да у него не будет подсветки кода, но должны быть функции позволяющие удобно писать программы, добавлять сторонние модули, настраивать их…
Компилировать и разбирать ошибки чтобы потом показать в редакторе юзеру.

А вот визуализацию кода пока отодвинул — потому что решения не вижу… как увижу — заменю компонент TMemo в проекте и будет подсветка…

Вот ещё немножечко вдохновительного монстра.


Эту вашу штуку я кое-как запустил под wine. Кошмарный ужас! :))
По поводу ошибок, ну редкий "просто редактор кода" не умеет подсвечивать ошибки на основе выхлопа компилятора. По крайней мере мой Eclipse это делает. Я специально создал проект для stm32f1x, и вместо реализации main() в main.c сделал простенький main.s (кстати, о расширениях файла: так уж повелось, что ассемблерные исходники либо .s, либо .S). Ошибки подсвечиваются, но не налету, а после компиляции.


Так что я всё ещё думаю, что лучшим приложением ваших усилий было бы написание расширения для любого из редакторов, т.к. я уверен, что вы слабо представляете что скрывается за словами "просто редактор кода". Поверьте, красивой подсветкой синтаксиса дело не ограничивается. А даже она у вас вызывает трудности. А если захочется фолдинга? А поиск-замена? А переходы к определениям? А ....? profit? Поищите, на хабре есть статья от Jet Brains о написании редактора кода.


Ошибки в вашем недоредакторе неотличимы от ключевых слов, подсвечиваются одинаково.


Про эмулятор конкретно стмовских камней не уверен, но, если не ошибаюсь, qemu умеет эмулировать armы. Да и зачем? Например: OpenOCD tool and Cortex-Debug VS Code plugin is used for debug purposes. Да и в эклипсе есть дебаггер.

Еще раз повторю — проект ссылку на который я дал в комментарии выше — это проба пера в подсветке кода… не получилось работать с объемными файлами — поэтому функциональность и не писалась дальше…

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

а все что вы пишите: фолдинг, поиск-замена, переходы к определениям — это как раз много проще для меня…

на счет qemu смотрел, помоему там нет ARMv7 :-( но инструментом отладки пока не занимался, так что нужно смотреть… а пока рано еще :-)
подсвечивать ошибки после компиляции как раз просто… компилятор все их выведет… пропарсить вывод и показать — это задачка для студента курса так 2го :-)

Поэтому все так делают, кроме я? :)


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

Имхо, странная идея. Компилятор лучше знает скомпилируется ли исходник, и почему — нет. А подсвечивать ошибки в коде без компилятора… ну… это написать свой компилятор с вот этим вот, и этими как их.

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

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

Скорее всего вы пересчитываете тэги при каждом инпуте и вероятнее всего храните весь текст в виде строк поля Text. Я бы посоветовал разобраться в паттерне MVP или MVVM и, например представлении документа в виде дерева.
что такое статический анализатор не знаю :-( расскажите — подумаю

Стати́ческий ана́лиз ко́да (англ. static code analysis) — анализ программного обеспечения, производимый (в отличие от динамического анализа) без реального выполнения исследуемых программ.

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

по richEdit — да, я правил Strings… причем пробовал отключать обновление, но все равно медленно работает…
Представление документа я прорабатывал, и строил даже структуры как раз в виде дерева… вопрос как потом это дерево быстро в richEdit передать, с сохранением форматирования… в общем у меня особо не получилось…

в MVP разбирался, правда для php использовал…

p.s. дайте мне построить свой велосипед! я не понимаю негатива, 99% проектов которые мы пишем (если это хобби, а не профессия) — все равно в стол… но почему то всегда найдется тот кто хочет по указывать что на каком столе делать…
Представление документа я прорабатывал, и строил даже структуры как раз в виде дерева… вопрос как потом это дерево быстро в richEdit передать, с сохранением форматирования… в общем у меня особо не получилось…
Сереализация — десереализация?
p.s. дайте мне построить свой велосипед! я не понимаю негатива, 99% проектов которые мы пишем (если это хобби, а не профессия) — все равно в стол… но почему то всегда найдется тот кто хочет по указывать что на каком столе делать…
Почему негатив? В принципе я за замену Keil на то что не будет обходится, скажем мне, в $3800 в год. Но мне лично жаль ваших усилий, потому что вы явно идете не туда, еще и неправильным путем. И что-то мне подсказывает что пока вас в конце ждет разочарование и и сожаление о куче потраченного времени. А еще я вижу что вы на самом деле плохо понимаете с какими проблемами вы еще столкнетесь. Поэтому и решил вас предостеречь, только и всего.
я не понимаю негатива, 99% проектов которые мы пишем (если это хобби, а не профессия) — все равно в стол…

Я своими велосипедами не делюсь. Поэтому понимаю негатив.
Я, правда, в данном случае нейтрален — мне Ваш проект ни для чего не пригодится.
я не понимаю негатива
Это же интернеты, тут так принято.
Хорошо хоть перестали постить троллейбус из буханки. Массовое производство и величие корпораций — это хорошо, но часто человеку хочется заморочиться и построить АЛУ на реле или прочее странное. И такие статьи, как ваша, делают хабр тортее.
Файл констант называется cmsis и издается самой ARM.
Вы же изобретаете Coocox.

Если копнуть глубже и задачу поделить на подзадачи:
1. Редактор
2. Компилятор/линкер
3. Прошивальщик
4. Отладчик

То мы видим зачатки редактора, который вряд ли когда-нибудь угонится за sublime, eclipse, notepad++, beans и т.п.
Все остальное все равно возьмете готовое.

по подзадачам вы правы

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

еще раз повторюсь — это не коммерческий продукт… пишу для себя… если кому интересно — велком…
поэтому критика ваша не туда идет…

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

а говорить что все вокруг изобретено — гм… так 99% ваших разработок в той же ситуации…

а мне вот интересно…

интересно написать редактор который был бы удобен мне самому…

интересно как сделать ту или иную функциональность…

вам нет?
ну тогда мои статьи точно будут не интересны, я не пишу коммерческие продукты для всех и не собираюсь соревноваться с продуктами которые существуют и дольше и в создании которых участвует больше людей…
Дело не в коммерции/некоммерции, у Вас нету четкого ТЗ.

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

1. объединение в проект. Уже написал одну версию… не нравится… получилось как у всех с теми же неудобствами… хотя некоторые вещи вспомнил из кокоса — буду писать их…

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

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

4. написать все таки редактор с подсветкой. уже перевернул synedit — нашел интересные вещи… но он все равно не подходит :-( там будет о чем писали выше (хранение кода в виде дерева, да и вообще некоторая предкомпиляция кода для простоты последующей работы с ним)

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

6. оптимизатор кода. здесь очень много набросок… не секрет что формат команд у ассемблера специфичен, и не всегда оптимальны те команды которые пишешь сразу (одно присваивание значений чего стоит)
опять все с середины.
проектирование начинается с «обзора имеющихся решений», обсуждения их достоинств и недостатков. И кокос можно и нужно под рукой иметь, как и другие среды, чтобы не по памяти действовать.

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

Кроме того, ассемблер нужен для 1-2 функций из сотни, надо — пишется в текущей среде важная процедура и всё.

CubeMX приучает людей к халяве, даже японцы радостно вопят, что вот проставил галки на пины и SAI, и программируешь, бед не знаешь. Все прерывания подняты, DMA настроены.
по всей видимости вы вообще не читали что написано выше…
В том-то и дело, что читал про «догоним и перегоним Far Manager» и лет 20 назад тоже начинал проекты с середины. Но это было в силу нехватки образования и опыта.
Вы не увидели желающих присоединиться именно потому что у вас нет четкой цели и плана. Люди не понимают, зачем им тратить время и ввязываться в подобную разработку. Потому что по тому как вы объясняете цели и задачи вы пишете редактор ради самого процесса и зачастую не зная как это делать. Возможно, то что вы задумали просто «бомбическое», но лично я пока вижу неструктурированные мысли на тему фич.
все что ниже — личное мнение. ничего не навязываю.

их я уже обошел…

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

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

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

  • на счет нотепада и сублима вы вообще не правы…
    их я уже обошел…
  • интересно как сделать ту или иную функциональность…


И если вам
интересно написать редактор который был бы удобен мне самому…

и
поэтому критика ваша не туда идет…

что тогда этот hello-world делает на хабре?

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

я уж не говорю, что вы не держите критику, у вас нету плана на разработку и главное — цели. была бы цель, вы бы составили тз, изучили бы решения вокруг, проанализировали что есть и наверняка пошли бы по верному пути. я никогда не пойму касту программистов, которые неразобравшись в инструментах — сразу лезут с написанием своих фреймворков, игровых движков и «редакторов\ide для {подставить нужное}».
да, да, простите, я забыл что хабр это ресурс для переводных (причем кривопереводных статей), а еще лучше наборов картинок о космосе, глубинах океана…

где минусовать найдете…

p.s. да… наверное так к нему и надо относиться… :-(((
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории