Comments 74
Хабр, я в тебя верил!
:-)
P.S. Минусы под статьями — восстание роботов? :)
мне вот если не интересно я и не минусую, но видать есть те кто по другому не может :-))
Программировать нужно в VIM, все остальное от лукавого!
Тупой вопрос: модуль/плагин для того же VSCode/Atom (whatever) настолько занудно писать, что проще свой редактор сделать, или есть непереносимость электроноподобных редакторов?
(или отпугнула недостаточная гибкость таковых?)
2. программирование на асме имеет некоторые гм… особенности…
то есть писать придется скорее всего не один плагин… и не два… и боюсь что и не три…
то что реализовано сейчас — это как верхушка айсберга. то что можно делать и руками с той же степенью эффективности, но список хотелок (которые буду делать) намного больше… так что проще писать свое чем подстраиваться под другой продукт десятком плагинов (еще не зная что можно реализовать плагином, а что нет...)
и что там от редактора? подсветка кода ?!
и судя по подсветке addnes — правильно не работает…
Я сам пишу много кода для STM32 на Си со вставками ассемблерного кода. Считаю такой подход наиболее оптимальным. Писать вчистую на ассемблере имеет смысл только из академического интереса.
Вижу какую-то фигню+сниппеты. Вот бы заменить какую-то фигню на хоть какой-нибудь редактор… Нет, серьёзно....
Или вам просто хочется/нравится писать на ассемблере? Если так, то вопросов более не имею :)
Хотя бы для того, что бы узнать как устроено то, под чего пишеться на C )
Это я все к тому, что даже с самым божественно-крутым редактором для ассемблера, писать на С все равно проще и легче; а если очень хочется, то можно ассемблерную вставку сделать.
Кто-то может затянуть известную песню про то, что современные компиляторы умные, они сами всё оптимизируют, лучше тебя, бросай ты это дело. Ничего подобного! Компиляторы тупы как пробка. Как то мне понадобилось синус вычислить. В начале вычисления возникал некий признак, который использовался в самом конце. Соответственно его нужно было где-то хранить. Я его засунул во флаг переноса, причем мне это ничего не стоило: попадал он туда как побочный эффект операции битового сдвига, лежал там тихонько, и в самом конце использовался посредством условной инструкции. Компилятор никогда бы до такого не додумался, выделил бы место где-нибудь на стеке (потому что свободных регистров не осталось). Это бы увеличило время выполнения функции процентов на 20 наверное. Вот такие вот дела.
Конечно это не значит, что приходится постоянно использовать ассемблер, нет. Просто ты используешь разные математические библиотеки, а вот они уже написаны на ассемблере. У TI, например, что fixed-point библиотека, что motor control, написаны как раз на нем.
Компилятор компилятору рознь, тут по всякому бывает в зависимости от множества факторов. Но в большинстве случаев вроде все хорошо. Разумеется, это еще и от задач зависит, у нас хитрой обработки сигналов как-то не попадалось, видимо.
Но вот синус мы уже считаем на этапе компиляции :)
Первый вопрос сразу — а на чем пишется редактор?
И второй — а рассматривался вариант взять готовое, например notepad++ и допилить плагинами? Тем более, у него исходный код открытый...
www.embitz.org/svn/listing.php?repname=EmBitz
тем более это же демка, разработка продолжается…
Как по мне, asm не совсем то на чем можно писать что-то большое (стоящее)
Драйвер работы с дисплеем, меню с 2-мя десятками подпрограмм. Каждая из которых переконфигурирует не только пины, но и NVIC и DMA…
Это слегка не тот инструмент для борьбы со сложностью…
P.S. лет эдак 7-8 один знакомый собирался прошивку писать для универских часов(с календарем и расписанием пар, дисплей 32×100 точек) на asm… короче не поднял…
года 2 назад похожий проект собирали другие студенты на Ардуине месяца за 4… оставив только дисплей…
Но вот писать свой редактор? «Для ассемблера»? С нуля? Странный. Странный выбор…
PS: Ну возьмите хотя бы уже готовый и накидайте того, чего не хватает. Тот же QtCreator. Нарисуйте к нему свой плагин с синтаксисом и прочим и будет счастье. Опять же — людям польза. Вот это вот все никто в трезвом уме даже запускать не будет. Лениво т.к. результат очевиден. А вот плагинчик под уже обсосанной вдоль и поперек IDE включить — это вполне себе пожалуйста.
Ну да бог с ним с креатором. Дело вкуса. Возьмите любой другой приличный редактор и расширьте его. Зачем тратить драгоценное время на бессмысленный мартышкин труд пытаясь реализовать то, что другие уже десять раз сделали по-определению лучше на порядок :-?
И да, EmBitz работает с Ассемблером, (я, например, подключил aarch64-linux-gnu для работы с 64 битной архитектурой, RPI 3 B+,A+). Для «голого железа» без Ассемблера не попишешь.
Кстати, FASMARM транслирует некоторые команды в код, для которых в GNU надо 2-3 команды вставлять или машинный код.
Картинка для FASMARM в текст не вставляется, вот её ссылка:
physicalcomputing.ru/images/Em2.jpg
(почему нельзя выбрать изображение на компьютере, а надо его в сеть сначала выгружать, да ещё и не вставляется?)…
Больше не буду тратить время на Хабро-комментарии.
на счет 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) -но мне не хватает быстродействия, видать должен быть другой подход для вывода текста… — пока есть только идея как переписать, чуть позже займусь (у меня в редакторе используется ТМемо, так что заменить один компонент на другой много времени не займет)
(Брать его самого за основу, наверное, не спортивно.)
Сейчас задача минимум запустить редактор.
Да у него не будет подсветки кода, но должны быть функции позволяющие удобно писать программы, добавлять сторонние модули, настраивать их…
Компилировать и разбирать ошибки чтобы потом показать в редакторе юзеру.
А вот визуализацию кода пока отодвинул — потому что решения не вижу… как увижу — заменю компонент 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% проектов которые мы пишем (если это хобби, а не профессия) — все равно в стол…
Я своими велосипедами не делюсь. Поэтому понимаю негатив.
Я, правда, в данном случае нейтрален — мне Ваш проект ни для чего не пригодится.
я не понимаю негативаЭто же интернеты, тут так принято.
Хорошо хоть перестали постить троллейбус из буханки. Массовое производство и величие корпораций — это хорошо, но часто человеку хочется заморочиться и построить АЛУ на реле или прочее странное. И такие статьи, как ваша, делают хабр тортее.
Вы же изобретаете 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 настроены.
их я уже обошел…
в чем, подскажите? то что в своем-мега-редакторе добавили пару окон? избыточно и ненужно.
для саблайма плагины пишутся на ура, вы бы прекрасно могли все это сделать потратя намного меньше времени на все это. с другой стороны — на саблайм уже есть готовые решения, как готовый и удобный редактор настроить под asm-разработку. есть много статей в гугле\яндексе.
вы же с серьезным лицом представляете свою тулзу как уберпафосное решение. зачем? это настолько выглядит любительски, особенно ваши доводы в комментариях:
на счет нотепада и сублима вы вообще не правы…
их я уже обошел…-
интересно как сделать ту или иную функциональность…
И если вам
интересно написать редактор который был бы удобен мне самому…
и
поэтому критика ваша не туда идет…
что тогда этот hello-world делает на хабре?
давайте все будем выкладывать «мой блокнот», «мой калькулятор» и прочие игрушки, заливая на файлопомойки и потом обижаться на комментарии, которые справедливо будут спрашивать «собственно, wtf!?».
я уж не говорю, что вы не держите критику, у вас нету плана на разработку и главное — цели. была бы цель, вы бы составили тз, изучили бы решения вокруг, проанализировали что есть и наверняка пошли бы по верному пути. я никогда не пойму касту программистов, которые неразобравшись в инструментах — сразу лезут с написанием своих фреймворков, игровых движков и «редакторов\ide для {подставить нужное}».
ARM Assembler Editor: Если гора не идет к Магомеду, Магомед идет к горе…