Comments 27
Весь мой опыт говорит, что кривой UI = кривой код проекта, поэтому даже запускать не стану.
но вообще конечно все буду переписывать наверное под WPF, сейчас интерфейс мне не нравиться, и многие задумки не знаю как реализовать на паскале
да и нет у меня линукса, так что проверять не на чем и коль нет человека который бы решал те или трудности — то и заморачиваться я не буду (нет времени на это)
Возможно вас это не убедит, но если вы рассмотрите идею сделать кроссплатформенное решение, возможно, это упростит формирование комьюнити разработчиков вокруг проекта
А не быстрее бы было сделать это плагином к Visual Studio Code? Кажется, что массу типового для IDE кода можно бы было не писать
Я бы, к примеру хотел бы видеть хороший плагин для подсветки синтаксисов ассемблеров (а их вагон и маленькая тележка, не только для АРМ-ов) как в VSCode, так и в QtCreator. И чтобы оно как-то автоматом подсвечивало синтаксис в зависимости от типа выбранного компилятора/архитектуры (ну, или хотя — бы был выбор как подсветить).
А то вроде плагинов много — но выбрать нечего, т.к. они или узко-спецализированные для какой-то одной архитектуры/тулчейна, или что-нибудь еще не то. :)
Тем более, что эти IDE-шки универсальные, т.к. поддерживают такие системы сборки как CMake или Qbs (Qbs — лучший выбор, т.к. поддерживает чисто железячные компиляторы, а не только GCC прямо «из коробки»). И можно создав однажды проект в этих системах сборки, открывать его в любых IDE и компилировать.
Это я к тому, что незачем (ИМХО) распалять ресурсы на пиление чего-то своего, а лучшее решение — проанализировать что уже есть и попытаться улучшить.
это не про вас… вообще про ситуацию…
то что вы описываете делают единицы, подсказать имеют возможность еще меньшее число (да их надо найти, им надо услышать, найти время на ответ, и чтобы вопрос им совсем ламерским не показался и наконец у них было время на ответ)
так что я может быть был бы и рад, но не люблю искать ответы в абстрактном гугле (очень и очень много времени уходит, и не всегда с результатом)
да и задачу надо было как то опробовать что ли алгоритмически, посмотрите исходный код — там много всяких заготовок, пробовал десятки вариантов пока нашел то что устраивает… и для этого хорошо это все пробовать на чем то простом, что знаешь и за примитивами к которому не нужно напрягать гугл, так как итак хватает алгоритмических и оптимизационных задач, чтобы еще терять время на задачи по осваивания не совсем понятного по возможностям нового языка в рамках работы плагином к какому то редактору… :-(
просто я реалист, начинать надо с чего то простого…
Что касается дела — а зачем ассемблер? Я в своё время написал тысячи строк на разных ассемблерах для многих видов MK, но когда перешёл на С — он сам собой отмер, за ненадобностью.
Опять же пользовался различными студиями но насколько помню наиболее приятная была Keil. И на асме там можно был писать.
На чём пишете прогу? VS?
Размышляя над целесообразностью дальнейшей разработки, вспомнил, что натыкался на материалы(раз, два), где к Visual Studio Code прикручивали компилятор GCC ARM вместе с отладкой. Однако для каждого проекта требовалось создание служебных файлов как для самой среды VSCode, так и для программируемого камня: мэйкфайл, стартап, скрипт линкера.
В итоге принял решение, что, конечно, своя IDE — это хорошо, но реализовывать то, что уже существует необходимости нет. Поэтому написал свое расширение для VSCode, которое автоматизирует создание проекта под определенный контроллер, его сборку и загрузку(OpenOCD или JLink), а также дебаг с помощью другого расширения.
Примерно месяц у меня ушел на базовый, но достаточный, функционал. С учетом того, что раньше с АПИ VSCode дел не имел и не писал на TypeScript. Сейчас потихоньку дополняю — недавно добавил pdf-viewer от Мозилы для просмотра мануалов и даташитов, которые автоматически загружаются для выбранного контроллера. Это заняло у меня несколько вечеров. Если бы все писал сам, то…
В VSCode полно расширений самых разных мастей и калибров: от подсветки кода и дополнения синтаксиса до аналога Тиндера. В основном это опенсорсные проекты, расположеные на гитхабе и среди них наверняка найдутся те, которые хотя бы частично, подойдут по функционалу и, при желании, их несложно переделать под свои нужды. Кроме того, насколько я знаю, можно сделать собственную сборку этого редактора, включив в нее только то, что необходимо.
Помимо VSCode существует множество других сред, типа Sublime, VIM, о которых, Автор наверняка знает. В них уже реализован необходимый минимум для работы: GUI, работа с файлами, вкладки с исходниками и т.д. Поэтому можно сосредоточится только на недостающем функционале.
* marketplace.visualstudio.com/items?itemName=qbs-community.qbs-tools
* habr.com/ru/post/526256
Чего пока не хватает — так это:
1. Нормальной подсветки файлов ассемблера (а их много разных бывает).
2. Нормальной подсветки файлов линкера (а их много разных бывает).
3. Нормальной подсветки компилеро/архитектуро специфичных ключевых слов компилятора и пр.
VitGo, Вот, было бы здорово если бы объединить усилия ;)
А то каждый лепит свой костыль (это и меня касается), а в итоге как в известной басни Крылова (про лебедя, щуку, рака). ))
по подсветке — у меня происходит полный разбор синтаксиса команды, посмотрите на варианты LDR… это далеко не фильтр по регулярным выражениям с ключевыми словами для подсветки…
про возможности VSCode + TypeScript:
у меня каждый файл проекта имеет свои символы, инклудные символы, глобальные символы (передаются в проект), спсисок инклудных файлов
соответственно, когда нужно получить список символов доступных в текущем файле идет просто запрос по инклудным файлам (соответственно запрос может быть перенаправлен глубже по инклудам) + добавляются символы текущего положения + добавляются глобальные символы с проекта
на TypeScript вы видите как это реализовать? подсказка — парсить внешний файлы с нуля при запросе списка символов — капец какая плохая идея (быстродействию капут) — я загружаю и обрабатываю все файлы проекта, и потом просто файлы обращаются друг к другу для получения имен символов, адресов, и так далее… то есть если файл отредактировали и потом перешли к другому файлу — то при обращении к нему — он никаких действий по поиску списка символов (просмотру и парсингу себя), просмотру файлов инклудов — не делает, они у него уже готовые в списках лежат…
вот в таком режиме работы — работа с символами более менее прозрачная и обеспечивает нужное быстродействие…
если вы можете написать такое на type script — то можно подумать над дальнейшим и объединять усилия… а я не хочу начать изучать новое, и потом узнать что в обработке файлов каждый файл изолирован, и нужно чесать левое уже пять раз для каждого желания правого… программируя редактор с нуля я вообще не думаю о каких то ограничениях свыше…
ну и все эти хипстерские установки и допиливания редакторов меня вечно веселят… наверное это круто… поставить редактор и потом еще допиливать и допиливать тот или иной дополнительный функциональный блок…
тут все в одном, работает из коробки, ничего ставить (кроме дров для ст-линк) не надо… но оказывается мы вдруг стали все блондинками, и нам при разработке стразы нужны обязательно, хипстерский дизайн редактора всем нужен…
нужна функциональность, и еще удобство — это то что можно и нужно обсуждать… а использование модного редактора, и крутых свистоперделок, скинов, шрифтов и прочего — это не со мной… это к блондинкам, они оценят
проблема тут в том что универсальное решение в виде VSCode накладывает массу ограничений на функционал. Поэтому выбор — сделать очередной недоредактор на VSCode, либо сделать максимально удобный редактор для ассемблера не ограничивая себя возможностями VSCode
UI отдает приятной олдскульностью. Сразу вспомнил свои проекты почти двадцатилетней давности на Delphi. Как оказалось, здесь тоже без Паскаля не обошлось.
я с удовольствием буду писать на ассемблере в любом другом редакторе
Очень круто было бы автоматическое коментирование мнемоник (как в ida). Ибо у арма вырвиглазный ассемблер — "так блевать и кидат". Особенно если сравнить с blackfin-ами
Небольшая идея развития системы подсветки/подсказок: синтаксис/семантика отдельных команд довольно быстро запоминаются, а вот что остаётся всегда, так это проблема повторного использования регистров. Было бы удобно набрав имя регистра, тут же видеть подсвеченными (либо списком в каком-то специальном окошке) предыдущие его использования (а ещё лучше более конкретно — модификации, либо вообще чтения и записи разными стилями).
гм… прикольная идея…
Да, в достаточно длинном коде при таком количестве регистров как у ARM (да ещё и с однообразными именами) начинаешь забывать что в котором регистре было, либо берёшь значение не из того, либо наоборот — занимаешь под что-то новое регистр, предыдущее содержимое которого ещё понадобится. Удобно было бы видеть что происходило с "текущим" регистром до этого. Да хотя бы как в IDA — подсветив все появления его имени в пределах видимого кода. А с вашим углублённым разбором инструкций можно ещё и цветами выделять чтение/запись. Либо где-то (в строке состояния? в окошке-подсказке?) показать вместе с номером строки ближайшую предыдущую команду (а то и несколько), где текущий регистр использовался.
Редактор ассемблера для ARM микроконтроллеров для компилятора gnu as. Старт