Если ваш вопрос не влез ни в одну из вышеперечисленных тем, вам сюда.
Ответить

Re: Котуинко

Пн мар 23, 2020 15:23:33

BOB51, на, поразвлекайся ... http://microsin.net/programming/avr/mix ... -code.html

Re: Котуинко

Пн мар 23, 2020 15:27:27

НЕЕ!
это только для АВРок - ёжли добавить тудыть еще ПИКи и MCS51 (а в перспективе еще чего...)
то уж слищшком много времени теории в ущерб практике будет.
Тем более без особой на то надобности - я ж придерживаюсь принципа использовать ассемблер как ассемблер, а си как Си (и то не более, чем в адуринкином референсе имеется).
8)
То уж пущай помоложе учебой занимаются.
:beer:
Последний раз редактировалось BOB51 Пн мар 23, 2020 15:30:54, всего редактировалось 1 раз.

Re: Котуинко

Пн мар 23, 2020 15:30:32

может быть неудачной
- если та же задача решена другим способом - неудачный вариант отметается, но задача то решена.
ходы записаны: :)
Пример, который я привёл выше - всего лишь одна из разновидностей классического решения при работе под " чистым ассемблером". И таких приёмов, некорректных по отношению к "чистому Си" достаточно много встречается.

требуется больше некоректных приемов

Re: Котуинко

Пн мар 23, 2020 15:34:41

НЕЕ!


Ну да, как доходит до дела -так в кусты...

Re: Котуинко

Пн мар 23, 2020 15:38:37

oleg110592
Это просто из желания подтвердить право на существование ассемблерных файлов в составе проекта на СИ?
8)
Тогда можно проще -
разрешено подключение файла на ассемблере, напиасного в соответствии с требованиями, установленными в описании компилятора СИ.
Все, что не соответствует вышеуказанным требованиям предварительно должно быть соответственно изменено.
:wink:

dosikus
Просто на сегодня такой вопрос не актуален.
(Как в свое время и Си с адуринкой).
:beer:

Re: Котуинко

Пн мар 23, 2020 15:56:36

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

Re: Котуинко

Пн мар 23, 2020 16:23:31

Приемов чисто ассемблерных для неперемещаемого кода вполне достаточно.
Однако их место именно в рамках ассемблера - для Си без модификаций (иногда достаточно кардинальной) они малопригодны.
8)
Насчет *.txt - вполне себе оправданно - не все же компиляторы однокомпонентные.
А там, где присутствует линкер обработка совершенно иная, чем в рамках атмелевского ассемблера для АВРок (и его аналогии для MCS51 - c51asm.exe).
Посему и ставятся *.txt как фактически текстовое расширение единственного обрабатываемого компилятором файла проекта.
Посему кстати и ограничение, правда в явном виде только в документации на c51asm.exe записанное:
"....
7.1 7.1 Restrictions
C51ASM only generates absolute object files instead of relocatable object modules. The entire object is
built in one step without calling a linker. Therefore the entire source code of an application program must
reside in a single file and its subsequent include files. The assembler directives that deal with relocatable
segments or external or public symbols have not been implemented, but are still reserved. These
include:
⵼ PUBLIC
⵼ EXTRN
⵼ SEGMENT
⵼ RSEG
C51ASM does not support the Intel Macro Processing Language (MPL). Only standard callable macros
and repeat macros are supported.
..."
Но ... поскольку оба компилятора от единого разработчика и по одной схеме делались, то данное и аврасм 2 также касается (может не так заметно в рамках IDE :roll: )
А вот у ПИКов мпасм по классической схеме с линкером.
Там компоновка многомодульных делается иначе.
В то же время вставка инклудом *.txt работает одинаково во всех трех компиляторах.
:beer:

Re: Котуинко

Пн мар 23, 2020 16:35:19

В то же время вставка инклудом *.txt работает одинаково во всех трех компиляторах.



include - лишь вставляет текст.
Вменяемо - либо инлайн асм либо модуль на асме .
Простыми словами - "ты страдаешь *** из-за пробелов в знании"...

Re: Котуинко

Пн мар 23, 2020 17:02:47

Приемов чисто ассемблерных для неперемещаемого кода вполне достаточно.
Насчет *.txt - вполне себе оправданно

1)таких приемов не встречал - просил уже показать, только не свои доморощеные, аж интересно стало. :shock:
2)тхт - тоже нигде не встречал, особенно в примерах производителей микроконтроллеров, тут имхо лучше или быть как все, или рот на замке :)

Re: Котуинко

Пн мар 23, 2020 18:51:26

Вот так и хочется "заткнуть инакомыслие".
:)))
Если удается получить удобный вариант, отличающийся от общеизвестного - сразу кучка "не позволямс".
(тем более, что тот вариант доказал свою работоспособность по серии проектов, в том числе и открыто опубликованных на Радиокоте).
8)
Относительно вставок файлов в Си проектах...
Собственно исходя из того, что компилятор Си сам распределяет ресурсы (планировка памяти, стек и прочие мелочи),
а ассемблер предусматривает полную свободу действий в тех же вопросах, уже имеет место вероятный "конфликт интересов".
Посему и оговорка должна быть - ассемблерные вставки (файлы) созданные с соблюдением требований компилятора Си.
8)
Самое интересное - "без цитаты на иноземный источник" доверия к высказываниям не имеется.
Ну да меня сие как-то не сильно огорчает - Все равно оценка по действующему макету выполняется.
:beer:

dosikus
Вот и я про то же самое:
.include "librus\trd2812_ma.txt"
абсолютно равноценно для компилятора ассемблера avrasm2 нижеследующему
.include "librus\trd2812_ma.asm"
ибо выполняет ВСЕГО ЛИШЬ ПОДСТАНОВКУ ТЕКСТА содержащегося в файле.
Даже при условии, что сам файл является самостоятельной компонентой (библиотечной подпрограммой/модулем).
Причем именно туда, куда это подключение будет выполнено при написании файла, его содержащего!
Другое дело ассемблер, содержащий раздельную обработку каждого из *.asm(*.s) файлов с последующей обработкой полученного результата редактором связей (линкером).
(Вполне вероятно в компиляторе GCC/Си именно такое решение применяется)
8)
А мне ранее приводили именно вариант инклуд подключения *.asm файлов в основном файле проекта для avrasm2 как образец модульного проекта на ассемблере (не на СИ!), отличающегося от такового с использованием *.txt файлов.
:wink:

Посему и обзываю свой вариант "слэнга"
"многофайловый проект под ассемблером".
:wink:

Re: Котуинко

Пн мар 23, 2020 19:20:15

Вот так и хочется "заткнуть инакомыслие"

не в том дело - форум публичный, тут новички обитают - а у всех языков есть правила - учится бы надо правильному. В принципе мне лично все равно, но неприятный осадочек остается - на другом, более взрослом форуме, наверняка канделябром по голове.
Пример, взрослый ассемблер
Код:
NCLUDE это директива, которая позволяет включать часть кода в конечную программу.
Вы найдете повторяющиеся строки:

mov dx,offset Hellostr               
mov ah,09h
int 21h
mov dx,offset  str2
mov ah,09h
int 21h
Давайте изменим этот шаге используя директиву INCLUDE. Создает файл Write.asm с кодом внутри:

mov ah,09h   ; функция вывода строки
int 21h
И переписываем шаг используя INCLUDE - write.asm:

MODEL   TINY
STACK 100h   
DATASEG
   Hellostr DB 'Hello First Step Site $'
   str2     DB 'Step 16 $'
CODESEG      
start:   
   mov ax,@data
   mov ds,ax
   mov dx,offset Hellostr               
INCLUDE write.asm
   mov dx,offset  str2
INCLUDE write.asm
   mov ah,04Ch
   mov al,1h
   int 21h

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

Re: Котуинко

Пн мар 23, 2020 21:41:19

Зато получим "пинка" при работе с классическими многокомпонентниками, включая мпасм (мплабIDE 8.92), любимый dosikusом кейл и прочие компиляторы с линкером.
Насчет начинающих - кому и "линейный примитив" достаточен, а кому поразбить "сверхлист" на кусочки...
Каждый свое выбирает.
Потому как те компиляторы, что с линкером вполне обоснованно могут матюкнуться на некорректно включенный файл (в опциях линкера не указанный).
А так - хотя бы единство оформления имеет место быть.
*.asm это самостоятельный файл, внешний по отношению к главному файлу проекта.
Данный файл обрабатывается компилятором отдельно и затем весь проект "сшивается" при помощи линкера.
А добавляемые (включаемые) в главный файл проекта текстовые файлы, которые затем обрабатываются как составляющая текста главного файла проекта - это обычные *.txt файлики.
8)
Кроме прочего я ставлю подключение только в главном файле проекта - а там и так все прекрасно видно...
К примеру у того же "замигателя" он вот такой

Добавлена "шапка" из описания фузов кристалла по умолчанию и для текущего проекта.
(аналогия с заголовочником ПИКовых).
А дальше перечень подключаемых фрагментов.
:roll:

Кстати... решил проверить мой "перемещаемый вариант"... на макетке...
И таки обнаружил ошибку - не доменял данные в концовке.
Еще один пинок-напоминание - ставить именованные константы вместо просто цифирек, дабы потом не выискивать - "где ж та клятая константа еще была??" (по прошествии энного времени от написания исходника).
:twisted:
Вот работоспособный текст:

:beer:

Re: Котуинко

Пн мар 23, 2020 22:05:31

Зато получим "пинка" при работе с классическими

не будет пинка, если с умом подходить - продожение выше примера:

Все готово, код из Write.asm будет включен в на место INCLUDE поэтому нам Write.asm не нужно компилировать. BAT файл будет как обычно.

..\bin\tasm program.asm
..\bin\tlink program.obj

все тоже самое можно сделать - в настройках проекта в любом ИДЕ или мэйкфайле, т.е. ПРОСТО не подключать к проекту файл Write.asm

Re: Котуинко

Пн мар 23, 2020 23:28:57

Не надо делать мешанину - в Вашем последнем примере линкер - то имеется в наличии!
Тем более tasm - это борландовская версия для I8086 в нюансах коего я особо не разбирался.
И опять же "требуются дополнительные настройки линкера"...
8)
А речь в случае АВРок речь идет об однокомпонентном ассемблере.
Но тогда это (инклуд текста) будет простая текстовая подстановка. Зато безо всяких "дополнительных настроек".
Суть разницы в том, что файл, скомпилированный отдельно может иметь свое пространство локальных имен.
Общими будут лишь те, что объявлены public/extern...
(Собственно модульное построение при максимальной возможной автономности каждого из модулей).
А при компиляции единым текстом - все пространство имен будет ЕДИНЫМ.
Да и стыковка сегментов различных областей памяти также или по заданию в опциях редактора связей или линейная, согласно последовательности размещения подключаемых фрагментов.
Также возможны нюансы при объявлении именованных констант/данных.
С учетом того, что при развитии тех же STM8\STM32 и иных МК, где имеется совмещенная область памяти программ/данных, снова происходит возврат к сегментированию разделов памяти в стиле I8086 (атрибуты сегмента - видимость, размерность, размещение и прочее...) приходится рассчитывать на усложнение правил работы с ассемблером в чистом виде до полного варианта к правилам МАСМ в ближайшей перспективе...
(Да минует нас необходимость работы под ассемблером для STM8\STM32! АМИНЬ!!! :evil: ).
:roll:
Выбор как обычно за пользователем - или заниматься индивидуальными настройками компилятора конкретно в каждом из проектов или использовать единую настройку по умолчанию.
Это уже у каждого по своему.
:beer:

Re: Котуинко

Вт мар 24, 2020 08:58:12

А речь в случае АВРок речь идет об однокомпонентном ассемблере.


Пора переходить на gcc, а не страдать ******...

Re: Котуинко

Вт мар 24, 2020 09:08:17

Не надо делать мешанину

мешанину не я начал:
"Мне удалось соорудить вариант слэнга для организации многофайловиков под ассемблером (одинаково работающий в рамках всех трёх семейств - mcs51/avr/pic)"

Писал же:
"под одну гребенку не причешешь"

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

Re: Котуинко

Вт мар 24, 2020 09:44:05

Да как раз не "кругами"...
Вопрос действительно заслуживает хорошей разборки.
:beer:
Расширение *.asm имеет право иметь файлик, исходник которого самодостаточен для автономной обработки компилятором.
При том, что у данного модуля (если использхуется механизм инклуд -вставок) не будет обращений к внешним меткам/данным основного проекта.
Т.е. после подключения текст файла не подвергается дополнительной ручной обработке.
В случае с классикой и линкером ручная обработка не потребуется.
А вот при инклуд -вставке... дело посложнее.
В каждом проекте имеются секции "холодной" и "горячей" инициализации (а также секция объявленных имен для констант, данных, РСФ).
Типичное расположение таких секций в начале главного файла проекта.
У каждого сложного модуля (библиотечный *.asm файл) также могут имется соответствующие разделы.
Допустимы два варианта...
Выделение соответствующих участков из модуля с их последующим размещением в соответствующих разделах главного файла проекта (и закрытием таковых в модуле методом превращения в комментарий).
После такой доработки файл модуля уже не может быть обработан компилятором автономно - и естественно не может иметь расширение *.asm - вот его и меняем на *.txt для копии размещенной в папке проекта (в папке библиотек исходный файл остается без изменений и сохраняет расширение *.asm).
И второй вариант - в самом модуле добавляется флаг контроля выполнения процедуры начальной инициализации.
Тогда модуль сохраняет возможность автономной обработки компилятором и ессно оставляем ему расширение *.asm...
Однако... во многих случаях и лишний флаг в ОЗУ штука не слишком надежная и инициализация в произвольном месте кода программы нежелательна...
Вышеуказанные проблемы - группировка разных по назначению участков кодов модулей в единых секциях (кода, данных, еепром) проекта решаются именно при раздельной обработке каждого файла с последующей передачей результатов редактору связей.
К примеру в
.code
присутствуют сегменты hard_init, soft_init и main_soft....
Но... то уже несколько более навороченные компиляторы требуются.
А в простом случае - используем заложенные в имеющихся возможности.
:roll:
Вобщем стоит внимательно поразмыслить/покопать и сформулировать...
:write:

ШИПЕНИЕ по поводу - "не надо заниматься" вряд-ли оправдывает возможности получить при помощи стандартного набора простых средств результат равный простому применению более навороченного софта.
:beer:

Re: Котуинко

Вт мар 24, 2020 10:00:09

Вопрос действительно заслуживает хорошей разборки.

хорошая разборка требует хорошего инструмента - лучше выбросить устаревший убогий Avrasm2 и взять нормальный ассемблер с линкером GNU-AS.
Для затравки:
http://www.count-zero.ru/2018/gnu_assembler/
Там поначалу рассмотрен чистый ассемблер

Re: Котуинко

Вт мар 24, 2020 10:10:50

oleg110592 писал(а):взять нормальный ассемблер с линкером GNU-AS.
согласен и давно это советую всем, кто не может расстаться с ассемблером.

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

Re: Котуинко

Вт мар 24, 2020 10:49:30

И далее...
8)
К вопросу о том "КТО СПРЫГНУЛ"
:wink:
:tea:

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

Собственно по Си - это разговор отдельный. Там еще не все из интересного выяснено - копаемся по мере возникновения вопросов.
8)
Ответить