Есть ли смысл учить ассемблер для написания ОС для ARM?

@RahDah06 · Регистрация: 30.06.2018

Author24 — интернет-сервис помощи студентам

Извините, если не в ту тему, не знал куда еще. Вопрос такой: я хотел бы попробовать себя в низкоуровневом программировании, а точнее, появилась странная (наверно) идея написать подобие ОС. Стоит ли учить для этого ассемблер, или хватит просто знаний C (у меня их сейчас нет)? И посоветуйте что еще для этого можно поизучать? Нашел несколько книг по изучению работы операционных систем (Modern Oeration System, H.Bos), пару статей. Стоит ли этим заниматься? К слову, сейчас у меня небольшой опыт в разработке на ASP.Net

@Rius · 01.02.2021, 19:01

Сообщение от ВитГо

сейчас ~~реализованы~~:

Написаны велосипеды!

Из того, что нет в vscode -

осмысленная (на ваш взгляд) подсветка

Ой, и всё...

Ещё есть Eclipse с плагином для GNU ARM. Там даже лучше по части отладки, чем в vscode. Но сама среда тормозная, т.к. написана на Java.

Сообщение от ВитГо

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

Если чего не хватает - пишут расширения. Их уже тысячи. Документация. Люди справляются как-то.

Сообщение от ВитГо

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

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

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

Это печально, сейчас основной язык для программирования - английский.

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

Ссылка выше. Там есть мануалы. Это не C#.

Сообщение от ВитГо

сейчас же используя более менее знакомый с института паскаль

Лучше освоить то средство, на котором будет быстрее.

Есть ли смысл учить ассемблер для написания ОС для ARM?

Вам для vscode надо было бы написать лишь

Линтер.
Свой "Intellisense".
Подсветку.
Создание шаблонного проекта для МК.
Автоматический стилизатор кода. Насколько это применимо для ассемблера.

Вы же упорно пишете то, что уже есть. Бери да пользуйся:

Управление проектом, хранение настроек всего и вся.
Возможность сборки проектов через Makefile, а это вся доступная функциональность того же упомянутого линкера. Не говоря уж о работе с исходниками, в том числе ассемблерными.
Отладка - очень важно! Если вы не пользуетесь отладкой, то у вас небольшие проекты, а ради таких заморачиваться собственным редактором - вообще смысла нет. Есть готовое расширение Cortex-Debug. Можно было бы присоединиться к его разработке.
Просмотр переменных в отладке.
Прошивка через программаторы. Makefile и консольные интерфейсы программаторов - рулят.
Редактор кода. Отличный редактор. У вас на такие фичи уйдут годы. Хотя бы просто потому, что над ними больше людей работает.
Поддержка систем контроля версий.
Система расширений, с которой среда почти не ограничена функциональностью и временем труда одного человека (вас).

@ВитГо · 01.02.2021, 19:13

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

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

@Rius · 01.02.2021, 19:41

Я лишь говорю, что вы тратите своё время неэффективно. А могли бы сделать средство, нужное другим ассемблерщикам.
Cortex-Debug вон кому вообще нужен, когда есть Keil, IAR и т.п.?
А ведь пользуются:

Ну... Увы.

@COKPOWEHEU · 01.02.2021, 19:56

Сообщение от ВитГо

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

На чистом асме под ARM не пишут. Да даже если бы и писали - для модульной разработки так и так придется вырабатывать стандарт стыковки объектников. Так почему не Си-шный?

Сообщение от ВитГо

если бы вы все таки смотрели что осуждаете - это было бы интересно...

Ваша среда интересна только вам. Тестировать, да даже смотреть ваши видюшки, будут только из любопытства. Кстати, у меня его недостаточно, то есть ни их смотреть мысли не возникло, ни тем более скачивать вашу программу.
На практике она бесполезна, поскольку есть куда более распространенные решения.
Ваш проект полезен лично вам для освоения программирования для ПК и изучения средств отладки МК. Тут пожалуйста, посоветовать готовы.

Сообщение от ВитГо

а так, глубину поставленной задачи вы до сих пор не поняли...

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

@ВитГо · 01.02.2021, 20:23

может быть вы и правы, хорошо что я пишу в первую очередь для себя :-) я то пользуюсь тем что пишу

@locm · 02.02.2021, 13:51

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

Лучше освоить то средство, на котором будет быстрее.

Знаете чем закончился мультик?
Тот кто утверждал что проще за 5 минут долететь, добрался до места назначения позже!

@Rius · 02.02.2021, 13:57

Не важно.

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

@ВитГо · 02.02.2021, 17:10

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

Знаете чем закончился мультик?
Тот кто утверждал что проще за 5 минут долететь, добрался до места назначения позже!

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

@Rius · 02.02.2021, 17:15

marus (Marcel Ball) освоил и у него 128 тысяч пользователей.
Вы не хотите осваивать и у вас один - Вы.
Всё правильно, я полагаю.

@ВитГо · 02.02.2021, 17:20

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

marus25 освоил и у него 128 тысяч пользователей.
Вы не хотите осваивать и у вас один - Вы.
Всё правильно, я полагаю.

хочу, но я реально понимаю что на сложных проектах не осваивают..

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

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

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

@Rius · 02.02.2021, 17:22

Сообщение от ВитГо

для меня это очевидно, а для вас ?

А мне жаль, что работа зря пропадёт...

@COKPOWEHEU · 02.02.2021, 17:30

Сообщение от ВитГо

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

И поэтому вы хотите заставить всех окружающих учить вашу среду?

Сообщение от ВитГо

хочу, но я реально понимаю что на сложных проектах не осваивают..

Сильно сомневаюсь что ваш проект объективно сложный. Субъективно - запросто. А на счет сложности освоения: на чем еще осваивать как не на учебных проектах?

Сообщение от ВитГо

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

А сами собираетесь активно писать на чистом асме?
Если да, то подумайте почему другие так не делают. Если нет, то оцените перспективы своей среды.

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

А мне жаль, что работа зря пропадёт...

Ну как пропадет. Человек опыт получит, а большего и не требуется.

@ВитГо · 02.02.2021, 19:56

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

А мне жаль, что работа зря пропадёт...

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

и это только одна из подзадач

Добавлено через 1 минуту

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

И поэтому вы хотите заставить всех окружающих учить вашу среду?

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

Добавлено через 29 секунд

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

Сильно сомневаюсь что ваш проект объективно сложный. Субъективно - запросто. А на счет сложности освоения: на чем еще осваивать как не на учебных проектах?

я тоже так думал... пока файлы по 6000 строк не начал обрабатывать :-))) а может я так плох, тоже может быть...
в конце концов когда вы писали про опыт - вы на 1000% правы...

Добавлено через 3 минуты

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

А сами собираетесь активно писать на чистом асме?
Если да, то подумайте почему другие так не делают. Если нет, то оцените перспективы своей среды.

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

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

@Rius · 02.02.2021, 20:08

Сообщение от ВитГо

другие не делают потому что банально нет среды,

Другие не делают, потому что

Уже есть компиляторы C/C++, которые выдают хороший код. На асме осталось делать самое платформозависимое, например переключение задач в RTOS.
Написание на ЯВУ быстрее и проще.
Есть множество готовых исходников, которые можно задействовать.
Код C/C++ портируется между разными процессорами с минимальным переписыванием или без оного.

@COKPOWEHEU · 02.02.2021, 20:38

Сообщение от ВитГо

хотя, какая разница какую среду учить... кокос, кейл, иар, все одно учим..

Распространенные среды могут и потом пригодиться. В смысле в профессиональной деятельности, а не хелло-ворлды писать. Опять же подумайте о поддержке: не лень будет постоянно обновлять свой продукт?

Сообщение от ВитГо

я тоже так думал... пока файлы по 6000 строк не начал обрабатывать

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

Сообщение от ВитГо

файлы по 6000 строк

Сдается мне, что-то не так с подходом. 6000 строк для одного файла это перебор. Ну 300, ну даже 1000 еще подъемно. Но не 6000.

Сообщение от ВитГо

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

Не угадали. На Асме не пишут потому что слишком трудоемко и слишком низкий уровень. Приходится больше изображать машинистку а также заниматься регистр-менеджментом, чем думать об алгоритме.
Плюс код на Си лишь немного уступает ассемблерному в производительности, а иногда и обгоняет.
Плюс контроль ошибок: в Си есть типы данных, массивы, структуры, все поименованные. В Ассемблере же максимум переменные элементарных типов, а дальше прямая работа с памятью.
Ради любопытства реализуйте на ассемблере такую простую вещь, как проход по связному списку. Без создания, без выделения памяти, только проход. Что-то в этом роде:

C

struct node{
  struct data{
    uint8_t data;
    char reserved[10];
  };
  struct node next;
};
...
struct node head;
...
struct node cur = head;
while( cur != NULL ){
    cur->data.data = 1;
    cur = cur->next;
}

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

Сообщение от ВитГо

если бы для си небыло HALa то на cmsis писать было бы так же сложно..

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

@ВитГо · 02.02.2021, 23:26

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

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

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

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

Сдается мне, что-то не так с подходом. 6000 строк для одного файла это перебор. Ну 300, ну даже 1000 еще подъемно. Но не 6000.

да ну ? откройте файл определений своей среды :-)) 6000 строк было получено из кокоса например, сейчас как раз меняю подход и делаю файлы немного по другому (в разбивке по устройствам), и с иерархией символов (потому что иметь кучу символов бестолку если нет нормальной навигации по ним), пока получается... причем дерево символов строится именно для того асм файла который редактируется... ну в общем много чего навертеть пришлось

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

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

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

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

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

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

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

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

ну я и на си не понимаю что автор имел ввиду.. но у меня просто опыта в си мало... так что спишем на мою неграмотность :-)

Добавлено через 5 минут

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

Другие не делают, потому что
Уже есть компиляторы C/C++, которые выдают хороший код. На асме осталось делать самое платформозависимое, например переключение задач в RTOS.

платформо независимость я прочувствовал с переходом от cortex-m3 на cortex-m4, прямо вот с gpio и начал чувствовать :-))

хотя если плотно сесть на hal наверное части граблей можно избежать...

@Voland_ · 02.02.2021, 23:31

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

Cortex-Debug

И кстати, надо будет попробовать. Совершенно недавно было (с Вами даже, вроде бы) обсуждение о дебаге в VS Code кортексов. Вы (или кто-то еще) давали настройку связи с GDB, но проблема на моей стороне оказалась в наличии лишь STLink v3, и отсутствия JTAG'а на плате. В итоге мне так и не удалось все это завести - тула со стороны VS Code никак не хотела правильно управлять GDB, и ничего не получалось. Но, возможно с этой тулой будет иначе. Попробую - отпишусь

@COKPOWEHEU · 03.02.2021, 00:42

Сообщение от ВитГо

а если еще это не просто текст а с различными токенами и синтаксисом то становится совсем весело

В ассемблере синтаксиса особого нет, для ЯВУ было бы куда хуже. А так - делим по строкам и никаких проблем.

Сообщение от ВитГо

то что проходит в каком нить avr studio

Там да, накручено. Основная проблема с PROGMEM, в то время не умели по-человечески описывать с точки зрения стандарта Си. Ну и сама особенность AVR что оперативка и флеш расположены в разных адресных пространствах, в ARM с этим проще.

Сообщение от ВитГо

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

А стоило отнестись серьезно.

Сообщение от ВитГо

а может наоборот, действительно на асме приходится думать об алгоритме больше чем в си ? :-) регистров то не так много :-)

Перечитайте мое сообщение. На асме приходится думать не об алгоритме, а о его реализации на конкретном железе.

Сообщение от ВитГо

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

Это свойство языка. Вы можете завораивать это в макросы, конфигураторы или различные копипасты. Получите слабое подобие нормального языка высокого уровня, потому что нет оптимизатора, нет проверок и других удобных плюшек.
Про кроссплатформенность вообще молчу. На Си придется переписывать лишь малую платформозависимую часть, на асме - все. Вот написал я когда-то для stm32f103 (arm) демку, рисующую трехмерную графику. А потом захотел потыкать палочкой gd32vf103 (risc-v). Так вот, портирование заняло очень мало времени. В основном на то чтобы разобраться как на контроллере с принципиально другой архитектурой работать с периферией.

Сообщение от ВитГо

видео вы не смотрели, поэтому тут можно не продолжать..

Ну разумеется, не смотрел. Как будто вы ожидали другого...

Сообщение от ВитГо

ну я и на си не понимаю что автор имел ввиду.. но у меня просто опыта в си мало... так что спишем на мою неграмотность :-)

А, я забыл что вы на Паскале пишете. Если не забуду, переведу на него.

Сообщение от ВитГо

платформо независимость я прочувствовал с переходом от cortex-m3 на cortex-m4, прямо вот с gpio и начал чувствовать :-))

Хм, а у меня особы проблем не было ни F103 -> L151 (там по-разному устроено), ни даже ->VF103 (вообще risc-v). Ну то есть макросы переписать пришлось, конечно, но сам код не изменился.

Сообщение от ВитГо

хотя если плотно сесть на hal наверное части граблей можно избежать...

На любителя. Я все же предпочитаю более простой подход, без ненужных абстракций над абстракциями.

@ВитГо · 03.02.2021, 00:53

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

В ассемблере синтаксиса особого нет, для ЯВУ было бы куда хуже. А так - делим по строкам и никаких проблем.

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

@COKPOWEHEU · 03.02.2021, 01:08

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

А, я забыл что вы на Паскале пишете. Если не забуду, переведу на него.

Как-то так.

Pascal

type
  node_ptr = ^node;
  node = record
    data : byte;
    reserved : array[1..10] of byte;
    next : node_ptr;
  end;
var
  head : node_ptr;
  node_cur : node_ptr;
begin
{инициализация связного списка. Это реализовывать не надо}
  new(head);
  new(head^.next);
  new(head^.next^.next);
  
{проходим по нему и что-то делаем с каждым элементом}
{вот это самое интересное}
  node_cur := head;
  while node_cur <> nil do begin
    node_cur^.data := 1;
    writeln(node_cur^.data);
    node_cur := node_cur^.next;
  end;
  
{деинициализация}
  dispose(head);
  dispose(head^.next);
  dispose(head^.next^.next);
end.

@Rius 11094 / 7013 / 1574 Регистрация: 25.05.2015 Сообщений: 21,176 Записей в блоге: 14
	02.02.2021, 13:57	27
	Не важно. Новые средства появляются для облегчения/ускорения разработки, а не только чтобы больше ресурсов потреблять. 0

@ВитГо 75 / 66 / 12 Регистрация: 09.02.2016 Сообщений: 902 Записей в блоге: 16
	02.02.2021, 19:56	33
	Сообщение от Rius А мне жаль, что работа зря пропадёт... Почему пропадет ? если бы я не написал то что написал - я бы даже не представлял себе сложность задачи... один разбор команд чего стоит.. текст правил разбора в исполняемый байткод преобразую, иначе не хватало быстродействия, а так 6000 строк обрабатывается почти мгновенно... и это только одна из подзадач Добавлено через 1 минуту Сообщение от COKPOWEHEU И поэтому вы хотите заставить всех окружающих учить вашу среду? ну заставить -это слишком категорично :-) хотя, какая разница какую среду учить... кокос, кейл, иар, все одно учим.. а у меня и учить нечего по сравнению с ними :-) Добавлено через 29 секунд Сообщение от COKPOWEHEU Сильно сомневаюсь что ваш проект объективно сложный. Субъективно - запросто. А на счет сложности освоения: на чем еще осваивать как не на учебных проектах? я тоже так думал... пока файлы по 6000 строк не начал обрабатывать :-))) а может я так плох, тоже может быть... в конце концов когда вы писали про опыт - вы на 1000% правы... Добавлено через 3 минуты Сообщение от COKPOWEHEU А сами собираетесь активно писать на чистом асме? Если да, то подумайте почему другие так не делают. Если нет, то оцените перспективы своей среды. да, я на нем и пишу.. потому и пришел к тому что в существующих средах на асме писать это пытка... другие не делают потому что банально нет среды, а без среды писать на асме очень и очень трудоемко... опять таки отсутствие библиотек, если бы для си небыло HALa то на cmsis писать было бы так же сложно.. 0

@Rius 11094 / 7013 / 1574 Регистрация: 25.05.2015 Сообщений: 21,176 Записей в блоге: 14
	02.02.2021, 20:08	34
	Сообщение от ВитГо другие не делают потому что банально нет среды, Другие не делают, потому что Уже есть компиляторы C/C++, которые выдают хороший код. На асме осталось делать самое платформозависимое, например переключение задач в RTOS. Написание на ЯВУ быстрее и проще. Есть множество готовых исходников, которые можно задействовать. Код C/C++ портируется между разными процессорами с минимальным переписыванием или без оного. 0

@ВитГо 75 / 66 / 12 Регистрация: 09.02.2016 Сообщений: 902 Записей в блоге: 16
	02.02.2021, 23:26	36
	Сообщение от COKPOWEHEU Ага, натыкался когда-то на разбор почему может быть сложно написать текстовый редактор, даже без подсветки и всего такого. В общем, одна из важнейших проблем - юзер добавляет текст куда угодно, а значит если хранить весь файл единым массивом, то придется постоянно его туда-сюда двигать. Вроде бы там предлагали хранить в виде списка или массива массивов чтобы двигать пришлось только в пределах кусочка. Сейчас не найду где я это видел. На Хабре наверное. и это тоже... а если еще это не просто текст а с различными токенами и синтаксисом то становится совсем весело... :-) хотя выход известен - указатели.. без них никак.. особенно интересно когда надо делать undo/redo - просто так хранить реплику текста нельзя (при движении undo/redo придется перепарсивать все заново, и так появляются инкрементальные обновления текста, с хранением указателей на изменившиеся строки и указателем какое изменение было... гы-гы.. просто песня) Сообщение от COKPOWEHEU Сдается мне, что-то не так с подходом. 6000 строк для одного файла это перебор. Ну 300, ну даже 1000 еще подъемно. Но не 6000. да ну ? откройте файл определений своей среды :-)) 6000 строк было получено из кокоса например, сейчас как раз меняю подход и делаю файлы немного по другому (в разбивке по устройствам), и с иерархией символов (потому что иметь кучу символов бестолку если нет нормальной навигации по ним), пока получается... причем дерево символов строится именно для того асм файла который редактируется... ну в общем много чего навертеть пришлось Сообщение от COKPOWEHEU Ну не знаю. Как по мне, HAL гораздо сложнее. Собственно, я им и не пользуюсь - хватает работы на регистрах. ну тогда от асма далеко не ушли... меня как раз больше эта строгая типизация в си напрягает... причем все эти стандарты си почему то зачастую очень выборочные для производителей сред... то что проходит в каком нить avr studio по синтаксису не применимо в кокосе... писал как то меню вложенное, так натра.ался с описанием пунктов меню указывающих друг на друга... это на авр.. потом начал переносить в кокос - и опять трах... понятно что всему можно научится, но блин, разговоры о стандартах си я после этого воспринимаю исключительно с улыбкой Сообщение от COKPOWEHEU Не угадали. На Асме не пишут потому что слишком трудоемко и слишком низкий уровень. Приходится больше изображать машинистку а также заниматься регистр-менеджментом, чем думать об алгоритме. а может наоборот, действительно на асме приходится думать об алгоритме больше чем в си ? :-) регистров то не так много :-) а на счет машинистки - вот мы уже доходим до понимания того что те функции которые дают распространенные среды - для асма мягко говоря не подходят зачастую. (как бы это не было странно)... и так появляется рутина... видео вы не смотрели, поэтому тут можно не продолжать.. Сообщение от COKPOWEHEU Не спорю, реализовать такое не составит больших проблем. Но будет ли это настолько же наглядно? Сможет ли рандомный мимокрокодил понять что хотел сказать автор? ну я и на си не понимаю что автор имел ввиду.. но у меня просто опыта в си мало... так что спишем на мою неграмотность :-) Добавлено через 5 минут Сообщение от Rius Другие не делают, потому что Уже есть компиляторы C/C++, которые выдают хороший код. На асме осталось делать самое платформозависимое, например переключение задач в RTOS. платформо независимость я прочувствовал с переходом от cortex-m3 на cortex-m4, прямо вот с gpio и начал чувствовать :-)) хотя если плотно сесть на hal наверное части граблей можно избежать... 0

@Voland_ 1978 / 1276 / 131 Регистрация: 04.01.2010 Сообщений: 4,607
	02.02.2021, 23:31	37
	Сообщение от Rius Cortex-Debug И кстати, надо будет попробовать. Совершенно недавно было (с Вами даже, вроде бы) обсуждение о дебаге в VS Code кортексов. Вы (или кто-то еще) давали настройку связи с GDB, но проблема на моей стороне оказалась в наличии лишь STLink v3, и отсутствия JTAG'а на плате. В итоге мне так и не удалось все это завести - тула со стороны VS Code никак не хотела правильно управлять GDB, и ничего не получалось. Но, возможно с этой тулой будет иначе. Попробую - отпишусь 0

@RahDah06 0 / 0 / 0 Регистрация: 30.06.2018 Сообщений: 31
		1
	Есть ли смысл учить ассемблер для написания ОС для ARM? 25.11.2020, 10:50. Показов 5079. Ответов 59 Метки arm, assembler, os, си (Все метки) Извините, если не в ту тему, не знал куда еще. Вопрос такой: я хотел бы попробовать себя в низкоуровневом программировании, а точнее, появилась странная (наверно) идея написать подобие ОС. Стоит ли учить для этого ассемблер, или хватит просто знаний C (у меня их сейчас нет)? И посоветуйте что еще для этого можно поизучать? Нашел несколько книг по изучению работы операционных систем (Modern Oeration System, H.Bos), пару статей. Стоит ли этим заниматься? К слову, сейчас у меня небольшой опыт в разработке на ASP.Net 0

@Rius 11094 / 7013 / 1574 Регистрация: 25.05.2015 Сообщений: 21,176 Записей в блоге: 14
	01.02.2021, 19:01	21
	Сообщение от ВитГо сейчас ~~реализованы~~: Написаны велосипеды! Из того, что нет в vscode - осмысленная (на ваш взгляд) подсветка Ой, и всё... Ещё есть Eclipse с плагином для GNU ARM. Там даже лучше по части отладки, чем в vscode. Но сама среда тормозная, т.к. написана на Java. Сообщение от ВитГо как только сталкиваешься с действительно сложными вещами (а у меня их достаточно) - то будет очень обидно выяснить что: никто так никогда не делал, и данная функциональность каким нить базовым редактором (vscode?) не поддерживается в плагинах.., а таких узких мест у меня в редакторе куча... даже более того, многие вещи приходилось переписывать не по одному (и далеко не по 5 раз) чтобы получать необходимое быстродействие. к кому можно обратиться с такими вопросами ? кто хорошо знает интерфейс плагинов внешнего редактора ? - на форумы идти (с абсолютной не ясностью результата) или саппорт писать (еще веселее) ? Если чего не хватает - пишут расширения. Их уже тысячи. Документация. Люди справляются как-то. Сообщение от ВитГо в той же подсветке было сломано столько копий, начиная от richedit и заканчивая synedit, пока пришло понимание что все равно придется писать свой класс, потому что вывод очень специфический, и текст исходников это дикая помесь объектов строк, символов, токенов, правил парсинга и прочих прелестей, причем зачастую привязаны они не к исходному файлу, а к проекту в целом... Это для вас копья, потому что пишете велосипед. А можно было взять готовое расширение по подсветке и посмотреть, как оно там работает. как это делать для vscode я не знаю, и внятных док не встречал (да, я лох, и английский не учил ни в школе, ни в институте, а со словарем, да еще без примеров, разбирать что то не просто, а тем более искать "там не знамо где", то что "примерно представляю как должно быть") Это печально, сейчас основной язык для программирования - английский. может быть в будущем попробую написать такое расширение, но еще раз повторюсь - мне нужна очень понятная документация, тем более что на С# я не писал никогда (хотя чую что надо учить уже), но тут опять проблема внятной документации или наставника (про курсы о том как вывести hello word даже писать не буду, такое ощущение что преподающие одну книгу прочитали, и теперь отбивают ее стоимость на других) Ссылка выше. Там есть мануалы. Это не C#. Сообщение от ВитГо сейчас же используя более менее знакомый с института паскаль Лучше освоить то средство, на котором будет быстрее. Вам для vscode надо было бы написать лишь Линтер. Свой "Intellisense". Подсветку. Создание шаблонного проекта для МК. Автоматический стилизатор кода. Насколько это применимо для ассемблера. Вы же упорно пишете то, что уже есть. Бери да пользуйся: Управление проектом, хранение настроек всего и вся. Возможность сборки проектов через Makefile, а это вся доступная функциональность того же упомянутого линкера. Не говоря уж о работе с исходниками, в том числе ассемблерными. Отладка - очень важно! Если вы не пользуетесь отладкой, то у вас небольшие проекты, а ради таких заморачиваться собственным редактором - вообще смысла нет. Есть готовое расширение Cortex-Debug. Можно было бы присоединиться к его разработке. Просмотр переменных в отладке. Прошивка через программаторы. Makefile и консольные интерфейсы программаторов - рулят. Редактор кода. Отличный редактор. У вас на такие фичи уйдут годы. Хотя бы просто потому, что над ними больше людей работает. Поддержка систем контроля версий. Система расширений, с которой среда почти не ограничена функциональностью и временем труда одного человека (вас). 0

@ВитГо 75 / 66 / 12 Регистрация: 09.02.2016 Сообщений: 902 Записей в блоге: 16
	01.02.2021, 19:13	22
	если бы вы все таки смотрели что осуждаете - это было бы интересно... а так, глубину поставленной задачи вы до сих пор не поняли... пишите сами для vscode, я не готов... в том числе и из-за языкового барьера... ну и из за того о чем писал выше... 0

@Rius 11094 / 7013 / 1574 Регистрация: 25.05.2015 Сообщений: 21,176 Записей в блоге: 14
	01.02.2021, 19:41	23
	Я лишь говорю, что вы тратите своё время неэффективно. А могли бы сделать средство, нужное другим ассемблерщикам. Cortex-Debug вон кому вообще нужен, когда есть Keil, IAR и т.п.? А ведь пользуются: Ну... Увы. 0

@COKPOWEHEU 4013 / 2560 / 429 Регистрация: 09.09.2017 Сообщений: 11,403
	01.02.2021, 19:56	24
	Сообщение от ВитГо ну это можно делать, просто я не стыкуюсь с си сейчас... На чистом асме под ARM не пишут. Да даже если бы и писали - для модульной разработки так и так придется вырабатывать стандарт стыковки объектников. Так почему не Си-шный? Сообщение от ВитГо если бы вы все таки смотрели что осуждаете - это было бы интересно... Ваша среда интересна только вам. Тестировать, да даже смотреть ваши видюшки, будут только из любопытства. Кстати, у меня его недостаточно, то есть ни их смотреть мысли не возникло, ни тем более скачивать вашу программу. На практике она бесполезна, поскольку есть куда более распространенные решения. Ваш проект полезен лично вам для освоения программирования для ПК и изучения средств отладки МК. Тут пожалуйста, посоветовать готовы. Сообщение от ВитГо а так, глубину поставленной задачи вы до сих пор не поняли... А она вообще есть? Я-то рассматриваю ваш проект как тестовый полигон для изучения вами соответствующих технологий. Так что не обольщайтсь, пользоваться этим никто не будет, вы впустую потратили время на запись роликов. 0

@ВитГо 75 / 66 / 12 Регистрация: 09.02.2016 Сообщений: 902 Записей в блоге: 16
	01.02.2021, 20:23	25
	может быть вы и правы, хорошо что я пишу в первую очередь для себя :-) я то пользуюсь тем что пишу 0

@locm 5931 / 2647 / 282 Регистрация: 28.10.2011 Сообщений: 9,993 Записей в блоге: 6
	02.02.2021, 13:51	26
	Сообщение от Rius Лучше освоить то средство, на котором будет быстрее. Знаете чем закончился мультик? Тот кто утверждал что проще за 5 минут долететь, добрался до места назначения позже! 1

@ВитГо 75 / 66 / 12 Регистрация: 09.02.2016 Сообщений: 902 Записей в блоге: 16
	02.02.2021, 17:10	28
	Сообщение от locm Знаете чем закончился мультик? Тот кто утверждал что проще за 5 минут долететь, добрался до места назначения позже! вот и я тоже самое говорю.. осваивать новый язык + среду, да еще в столь сложном проекте - это точно не будет быстро 0

@Rius 11094 / 7013 / 1574 Регистрация: 25.05.2015 Сообщений: 21,176 Записей в блоге: 14
	02.02.2021, 17:15	29
	marus (Marcel Ball) освоил и у него 128 тысяч пользователей. Вы не хотите осваивать и у вас один - Вы. Всё правильно, я полагаю. 0

@ВитГо 75 / 66 / 12 Регистрация: 09.02.2016 Сообщений: 902 Записей в блоге: 16
	02.02.2021, 17:20	30
	Сообщение от Rius marus25 освоил и у него 128 тысяч пользователей. Вы не хотите осваивать и у вас один - Вы. Всё правильно, я полагаю. хочу, но я реально понимаю что на сложных проектах не осваивают.. тем более на проекте который еще не до конца осмыслен и описан... одно дело переносить и усовершенствовать проект который уже хотя бы оформлен алгоритмически, и другое когда ни языка не знаешь, ни того что хочешь... да еще это помножить на необходимость писать расширение для чужого редактора с мутно понятной документацией (из за языкового барьера)... для меня это очевидно, а для вас ? ну я же писал - в первую очередь пишу редактор для себя... а на счет остальных - я вообще не встречал тех кто на асме пишет (больше чем инлайном)... так что особо тут горевать не о чем... если бы такой человек нашелся - конечно работа пошла бы быстрее, но коль нет - значит будет идти чуть медленнее, это не самое страшное в хоббийной разработке 0

	03.02.2021, 01:08

@Rius 11094 / 7013 / 1574 Регистрация: 25.05.2015 Сообщений: 21,176 Записей в блоге: 14
	02.02.2021, 17:22	31
	Сообщение от ВитГо для меня это очевидно, а для вас ? А мне жаль, что работа зря пропадёт... 0

@COKPOWEHEU 4013 / 2560 / 429 Регистрация: 09.09.2017 Сообщений: 11,403
	02.02.2021, 17:30	32
	Сообщение от ВитГо вот и я тоже самое говорю.. осваивать новый язык + среду, да еще в столь сложном проекте - это точно не будет быстро И поэтому вы хотите заставить всех окружающих учить вашу среду? Сообщение от ВитГо хочу, но я реально понимаю что на сложных проектах не осваивают.. Сильно сомневаюсь что ваш проект объективно сложный. Субъективно - запросто. А на счет сложности освоения: на чем еще осваивать как не на учебных проектах? Сообщение от ВитГо ну я же писал - в первую очередь пишу редактор для себя... а на счет остальных - я вообще не встречал тех кто на асме пишет А сами собираетесь активно писать на чистом асме? Если да, то подумайте почему другие так не делают. Если нет, то оцените перспективы своей среды. Сообщение от Rius А мне жаль, что работа зря пропадёт... Ну как пропадет. Человек опыт получит, а большего и не требуется. 0

@COKPOWEHEU 4013 / 2560 / 429 Регистрация: 09.09.2017 Сообщений: 11,403
	03.02.2021, 00:42	38
	Сообщение от ВитГо а если еще это не просто текст а с различными токенами и синтаксисом то становится совсем весело В ассемблере синтаксиса особого нет, для ЯВУ было бы куда хуже. А так - делим по строкам и никаких проблем. Сообщение от ВитГо то что проходит в каком нить avr studio Там да, накручено. Основная проблема с PROGMEM, в то время не умели по-человечески описывать с точки зрения стандарта Си. Ну и сама особенность AVR что оперативка и флеш расположены в разных адресных пространствах, в ARM с этим проще. Сообщение от ВитГо но блин, разговоры о стандартах си я после этого воспринимаю исключительно с улыбкой А стоило отнестись серьезно. Сообщение от ВитГо а может наоборот, действительно на асме приходится думать об алгоритме больше чем в си ? :-) регистров то не так много :-) Перечитайте мое сообщение. На асме приходится думать не об алгоритме, а о его реализации на конкретном железе. Сообщение от ВитГо а на счет машинистки - вот мы уже доходим до понимания того что те функции которые дают распространенные среды - для асма мягко говоря не подходят зачастую. (как бы это не было странно)... и так появляется рутина... Это свойство языка. Вы можете завораивать это в макросы, конфигураторы или различные копипасты. Получите слабое подобие нормального языка высокого уровня, потому что нет оптимизатора, нет проверок и других удобных плюшек. Про кроссплатформенность вообще молчу. На Си придется переписывать лишь малую платформозависимую часть, на асме - все. Вот написал я когда-то для stm32f103 (arm) демку, рисующую трехмерную графику. А потом захотел потыкать палочкой gd32vf103 (risc-v). Так вот, портирование заняло очень мало времени. В основном на то чтобы разобраться как на контроллере с принципиально другой архитектурой работать с периферией. Сообщение от ВитГо видео вы не смотрели, поэтому тут можно не продолжать.. Ну разумеется, не смотрел. Как будто вы ожидали другого... Сообщение от ВитГо ну я и на си не понимаю что автор имел ввиду.. но у меня просто опыта в си мало... так что спишем на мою неграмотность :-) А, я забыл что вы на Паскале пишете. Если не забуду, переведу на него. Сообщение от ВитГо платформо независимость я прочувствовал с переходом от cortex-m3 на cortex-m4, прямо вот с gpio и начал чувствовать :-)) Хм, а у меня особы проблем не было ни F103 -> L151 (там по-разному устроено), ни даже ->VF103 (вообще risc-v). Ну то есть макросы переписать пришлось, конечно, но сам код не изменился. Сообщение от ВитГо хотя если плотно сесть на hal наверное части граблей можно избежать... На любителя. Я все же предпочитаю более простой подход, без ненужных абстракций над абстракциями. 0

@ВитГо 75 / 66 / 12 Регистрация: 09.02.2016 Сообщений: 902 Записей в блоге: 16
	03.02.2021, 00:53	39
	Сообщение от COKPOWEHEU В ассемблере синтаксиса особого нет, для ЯВУ было бы куда хуже. А так - делим по строкам и никаких проблем. ну если метки не обрабатывать то да... и команды не разбирать... в общем если делать просто текстовый редактор с подсветкой токенов по маске не задумываясь о том что же все таки за команда написана... 0