Embedded OS

GS> Если многобайтные операции более эффективны, чем однобайтные - в принципе GS> может производиться чтение/запись сразу по несколько байт (при GS> необходимости GS> с предварительным выравниванием). При интенсивной обработке строк эффект GS> Типичный пример, встречающийся в литературе - ускорение работы REP MOVSB, GS> путём замены на REP MOVSW (x86).

grep

Reply to
Kirill Frolov
Loading thread data ...

Hello George.

31 Mar 05 00:36, you wrote to Alexander Aleshenko:

AA>> Коллеги, может хватит выяснять чья пиписка толще, круче и длинее, AA>> конференция не место для этого. Жора Шепелев, GS> Специально для тебя придётся повторить, мне не нравится, когда в мой GS> адрес используется эта кликуха.

Вообще-то это не "кликуха" совсем. Это то же самое, если я буду обижаться на "Лёша", вместо "Алексей"

Alexey

Reply to
Alexey Boyko

Привет, *Dima*!

/среда, 30 марта 2005/ *Dima Orlov* писал(а) к *Andrey Solomatov* по поводу *Текстовые строки (было: Embedded OS):*

[кусь] >> .... >> IEC 1131 Structured Text Overview This high-level language >> resembles Pascal or >> Basic, and, in fact, people trained in computer programming >> languages often >> ... >> ------------ >> ;))

DO> Вот-вот. Если что-то подобно одновременно и паскалю и бейсику, то туда DO> же и Си можно отнести и кучу других языков.

Ну, если уж вспомнить бейсик (не тот, который "визуал"), то выяснится, что на IEC 1131 он похож весьма слабо: LET a = b ;), а C здесь вообще не пахнет. Можно конечно вспомнить первоисточник АЛГОЛ - но его уже точно забыли (по сравнению с pas :)

[кусь]
Reply to
Andrey Solomatov

Hello, Andrey Solomatov !

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

Пахнет. Те же структуры.

Именно, я собственно это уже сделал (вспомнил).

С уважением, Дима Орлов.

Reply to
Dima Orlov

Здравствуйте, Уважаемый Dima!

Wed Mar 30 2005 22:33, Dima Orlov wrote to Olga Nonova:

DO> .... Си такой же DO> процедурный язык, как алгол, паскаль и тому подобное.

Позвольте не поверить. Чтобы не возбуждать лишний раз неприятия реальной жизни, даю ссылку на мнение авторитетного человека, который досконально Вам обьяснит, почему Си много хуже нормальных ЯВУ. Ловите:

formatting link
DO> Что же до PLC, то появление возможности программировать их не только на DO> совершенно ублюдочном языке релейно-контакторных схем, но и на DO> процедурных языках - уже большой прогресс.

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

Всего Вам Хорошего Ольга

Reply to
Olga Nonova

Hello Vladimir.

31 Mar 05 17:14, you wrote to me:

VV> Синтаксис ассемблера должен быть алгебраическим. Первыми до этого VV> догадались AD. Вместо совершенно непонятных мнемоник надо писать VV> просто и ясно:

VV> A = A + 1; VV> [fsr21] = W; VV> if nz jump label_12345;

А почему бы не обратная польская запись "A @ 1 + A !" ? ;))))))

Впрочем, есть же Temic MARC4 (4-х разрядный стековый процессор)

Alexey

Reply to
Alexey Boyko

Thu Mar 31 2005 09:37, Alexey Boyko wrote to Alexander Golov:

AG>>>> И чем же ПИКи такие уродливые? AB>>> Ты же кидал листинги - абсолютно нечитаемые. AG>> Отлично читаемые, красивые и приятные в отличие от...

AB> Hе, правда. Если бы 'movwf mem' называлась 'ld mem', а 'movfw mem' AB> называлась 'st mem' мне было бы гораздо понятней. Мышление у меня было бы AB> "аккумулятороцентричное". А то поди на первый взгляд разберись, где wf, а AB> где fw.

AB> Вот что делает эта команда? AB> movf fsr2l,w,c

AB> Даже в ARM-е "mov" - двухоперандный, а тут три. Если "fsr2l" - какой-то AB> адрес, а про "w" - я уже слышал, то что такое "c"? И что означает "f" в AB> "movf"?

Синтаксис ассемблера должен быть алгебраическим. Первыми до этого догадались AD. Вместо совершенно непонятных мнемоник надо писать просто и ясно:

A = A + 1; [fsr21] = W; if nz jump label_12345;

И.т.д. и.т.п.

VLV

"Быть честным - лучший способ оставаться бедным" (c) Hаполеон Бонапарт

Reply to
Vladimir Vassilevsky

Hello, Olga Nonova !

Вас никто не заставляет ничему верить. Все, что я говорю легко проверяется, и в отличие от ваших лозунгов, не отягощенных никакой аргументацией, аргументировано.

Для меня ни он ни его мнение никаким авторитетом не являются, тем более, что ни о каком выборе ЯВУ в мелком embedded речь не идет, альтернатив С (иногда ограниченному С++) просто не существует. Только ассемблер. И не надо меня за паскаль агитировать, я на нем написал многие десятки тысяч строк и в отличие от вас его знаю, хотя уже несколько лет ничего на нем не писал.

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

С уважением, Дима Орлов.

Reply to
Dima Orlov

Thu Mar 31 2005 18:17, Alexey Boyko wrote to Vladimir Vassilevsky:

VV>> Синтаксис ассемблера должен быть алгебраическим. VV>> A = A + 1; AB> А почему бы не обратная польская запись "A @ 1 + A !" ? ;)))))) AB> Впрочем, есть же Temic MARC4 (4-х разрядный стековый процессор)

[SP--] = A; A = 1; A += [++SP];

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

VLV

"Быть честным - лучший способ оставаться бедным" (c) Hаполеон Бонапарт

Reply to
Vladimir Vassilevsky

Alexey, ты ещё здесь сидишь?

Среда Март 30 2005 08:30, Alexey Boyko wrote to Alexander Golov:

AOS>>> И чем же именно? И чем АВРы уродцы? ПИКи поуродливее будут... AOS>>> Вот у кого действительно мнемоники ужасные - так это у ПИКов. AG>> И чем же ПИКи такие уродливые? AB> Ты же кидал листинги - абсолютно нечитаемые.

Посмотри мои листинги - вполне читаемые. Хинт - можно использовать макросы!

AG>> АВРы поуродливее будут... Вот у кого AG>> действительно мнемоники ужасные - так это у АВРов. AB> Их хоть читать можно.

;) С трудом. Одних разновидностей MOV'ов столько, что тоже напрашивается использование макросов.

AB> ps: Понеслась ;))))))))))))

;-)

Георгий

P.S. В споре иногда рождается истина. Если, конечно, спорщики не переходят на личность собеседника...

Reply to
George Shepelev

Thu Mar 31 2005 16:48, Olga Nonova wrote to Dima Orlov:

DO>> .... Си такой же DO>> процедурный язык, как алгол, паскаль и тому подобное.

ON> Позвольте не поверить. ON> Чтобы не возбуждать лишний раз неприятия реальной ON> жизни, даю ссылку на мнение авторитетного человека, который досконально ON> Вам обьяснит, почему Си много хуже нормальных ЯВУ. Ловите:

ON>

formatting link
Довольно мутная статья какого-то Лёхи, который пытается собрать в кучу разбегающиеся в разные стороны мысли, постоянно перепрыгивая с одного на другое, путанные объяснения на пальцых без конкретных аргументов и примеров, за исключением какой-то дури насчет писания кем-то обработки матрицы 10х10 более года. Какие-то сторонние излияния про тупость студентов. Притом, что это насчет PC, где в общем то есть выбор между Си и Паскалем, чего не скажешь об эхотаге.

Почитайте что-нибудь более авторитетное, например Р.У.Себеста. "Основные концепции языков программирования", чтобы хотя бы в общем представлять классификацию языков.

wbr, Andy

Reply to
Andy Mozzhevilov

Привет!

Thu Mar 31 2005 04:43, Maxim Polyanskiy wrote to Alexander Golov:

... AG>> static volatile near bit C @ (( unsigned ) & STATUS * 8 ) + 0 ;

MP> Асм - вид сбоку.

Нет, здесь только С и больше ничего.

AG>> HourVolInt += Int ; AG>> HourVolFrac += Frac ;

MP> Hикакой гарантии что сдесь C не срется. Просто везение.

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

AG>> if ( C ) HourVolInt ++ ; AG>> И ведь почему-то работает.

MP> Откомпилируешь чем нибудь другим - перестанет.

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

Александр Голов, Москва, snipped-for-privacy@mail.ru

Reply to
Alexander Golov

Привет!

Thu Mar 31 2005 08:19, Andrew O. Shadoura wrote to Alexander Golov:

...

AOS>>>>> И чем же именно? И чем АВРы уродцы? ПИКи поуродливее будут... Вот у AOS>>>>> кого действительно мнемоники ужасные - так это у ПИКов.

AG>>>> И чем же ПИКи такие уродливые?

AB>>> Ты же кидал листинги - абсолютно нечитаемые.

AOS> Согласен. Просто ужас какой-то. По мнемонике и не скажешь так сразу, что AOS> команда делает.

Не согласен. Просто чудо! По мнемонике сразу всё видно и сразу понятно...

...

AG>>>> АВРы поуродливее будут... Вот у кого действительно мнемоники ужасные - AG>>>> так это у АВРов.

AB>>> Их хоть читать можно.

AG>> Абсолютно нечитаемые.

AOS> Конкретные примеры: неужели не понятно, что ld - загрузка в регистр, AOS> brnz - ветвление, если не ноль, sbrs - пропустить, если в регистре бит AOS> установлен. А про add, sub, inc, dec и т.д. даже и говорить ничего не AOS> надо.

Совершенно бессмысленные заклинания. Ничего не понять!

PS: Для тех кто в танке намекаю прямым текстом на пословицу "про вкус и цвет".

Александр Голов, Москва, snipped-for-privacy@mail.ru

Reply to
Alexander Golov

Hi!

Olga Nonova сообщил в новостях следующее:

Вам

адреса? А по сути - полная ахинея, автор не видит за деревьями леса. И если в протвопоставлении C vs Asm можно углядеть некоторые аргументы (хотя они и лежат не в технической плоскости), то противопоставлять С++ "вообще" и Паскаль "вообще" можно только в единственном ракурсе - С стандартизован, а Паскаль нет. А в остальном различий между ними много меньше, чем между реализациями одного языка разных производителей. Способ хранения строк, begin-end против скобок, словечко with - какое это может иметь значение? Для программиста, я имею в виду, а не для словоблудия. Основная мысль автора (ну, насколько я понял этот невнятный текст) -

- что нагромождение языковых средств, появление новых конструкций не есть хорошо. Тезис, в общем, верный, но именно С, в силу его стандартизации и обеспечивает стабильность и преемственность! А приводить в качестве примера стабильности Борландовский Паскаль может... ну только очень молодой человек :-) Опять же, автор, насколько я понимаю, других С, кроме Борландового не видел, да даже не Борландового вообще, а именно от BCB. А расширения его - да, есть, но они вполне естественны и понятно откуда растут - дабы иметь общую с Делфи VCL. В свой Паскаль тот же Борланд много больше конструкций ввел, в том числе и принципиально меняющих язык.

Примите уверения в совершеннейшем к Вам почтении

Reply to
Sergey Zabelin

Привет!

Thu Mar 31 2005 09:37, Alexey Boyko wrote to Alexander Golov:

...

AG>>>> И чем же ПИКи такие уродливые?

AB>>> Ты же кидал листинги - абсолютно нечитаемые.

AG>> Отлично читаемые, красивые и приятные в отличие от...

AB> Hе, правда. Если бы 'movwf mem' называлась 'ld mem', а 'movfw mem' AB> называлась 'st mem' мне было бы гораздо понятней.

Вообще-то странно, что сохранение wreg в памяти у тебя ассоциируется с неким ld, а загрузка с st. А если серьёзно, я как-то ещё на заре освоения PIC16 написал в том числе и макросы вроде: STW, LDW#, но в дальнейшей практике их уже не использовал, потому что нужно это только для удовлетворения привычки к предыдущей любимой архитектуре, что со временем проходит.

AB> Мышление у меня было бы "аккумулятороцентричное".

Wreg это не аккумулятор, а лишь вспомогательный регистр. И чисто практически нет никакой нужды в "wreg-центричности" (интересно, а чтобы тебе показалось правильным применительно к dsPIC?).

AB> А то поди на первый взгляд разберись, где wf, а где fw.

Нет с этим никаких проблем, говорю как писавший до PIC'ов в течении 10 лет как раз: LDA, STX, LDY.

AB> Вот что делает эта команда? AB> movf fsr2l,w,c

Это "movfw fsr2l", MPASM даже поддерживает этот синоним для PIC16, для PIC18, правда, необходимо явно объявить макрос.

AB> Даже в ARM-е "mov" - двухоперандный, а тут три.

Тут операнд один, остальное -- флажки.

AB> Если "fsr2l" - какой-то адрес, а про "w" - я уже слышал, то что такое "c"? AB> И что означает "f" в "movf"?

Ты серьёзно собрался обсуждать листинг выданный компилятором как демонстрацию вида исходника на асме данного МК? Для этого компилятора нормально выдать какую-нибудь ерунду вроде:

incf ?a_ADC_Work^(__Lparam& (0+65280)),f decfsz (?a_ADC_Work+1)^(__Lparam& (0+65280)),f goto l26 bsf 3977,0,c ;volatile movlb F1327 shr (0+8) movlw -2 addwf F1327& (0+255),f,b movlb F1328 shr (0+8) incf F1328& (0+255),f,b movlw 3 cpfslt F1328& (0+255),b goto l28 goto l11 l28: bcf _Calibrate_ADC_Fl/(0+8),_Calibrate_ADC_Fl & (0+7),c movlw 4 movff wreg,F1327 btfss _Calibrate_ADC_Fl/(0+8),_Calibrate_ADC_Fl & (0+7),c goto l30

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

ReadData btfsc TxReadyFl ; = Данные не передаются. return ; ; Найти пролог ReadData0 rcall ReadByte ; Принять байт bc ReadDataE ; = Нет данных ReadData2 xorlw 0x5D ; bnz ReadData0 ; = Не начало пролога rcall ReadByte ; Принять байт bc ReadDataE ; = Нет данных xorlw 0x5D ; bnz ReadData0 ; = Не второй байт пролога ; Принять область данных movlw 17 ; Размер области данных movwf Work0 ; Инициализировать счётчик clrf TxCheck+0 ; Сбросить контрольную сумму clrf TxCheck+1 ; lfsr 2,TxBuffer ; Установить указатель на буфер ReadData1 rcall ReadByte ; Принять байт bc ReadDataE ; = Нет данных movwf postinc2 ; Сохранить байт в буфере addwf TxCheck+0 ; Добавить в контрольную сумму movlw 0 ; Старший байт addwfc TxCheck+1 ; decfsz Work0 ; Перевести счётчик принятых байтов bra ReadData1 ; ... btg LED ; Переключить светодиод bsf TxReadyFl ; Поставить задание на передачу ReadDataE return ; ; ReadByte bsf c ; C=1 btfsc RXE ; = Есть данные return ; ; bcf RD# ; Выставить сигнал RD movfw portb ; Прочитать данные bsf RD# ; Снять сигнал RD bcf c ; C=0 return ;

Александр Голов, Москва, snipped-for-privacy@mail.ru

Reply to
Alexander Golov

Приветствую, Alexander!

Однажды, 01.04.05 3:57:48, Alexander писал к Andrew O. Shadoura по поводу "Паскаль в эхотаге (было: Embedded OS)".

AOS>>>>>> И чем же именно? И чем АВРы уродцы? ПИКи поуродливее будут... Вот у AOS>>>>>> кого действительно мнемоники ужасные - так это у ПИКов. AG>>>>> И чем же ПИКи такие уродливые? AB>>>> Ты же кидал листинги - абсолютно нечитаемые. AOS>> Согласен. Просто ужас какой-то. По мнемонике и не скажешь так сразу, AOS>> что команда делает.

AG> Hе согласен. Просто чудо! По мнемонике сразу всё видно и сразу понятно...

Hе согласен. Просто ужас! По мнемонике ничего не видно и не понятно...

AG>>>>> АВРы поуродливее будут... Вот у кого действительно мнемоники ужасные AG>>>>> - так это у АВРов. AB>>>> Их хоть читать можно. AG>>> Абсолютно нечитаемые. AOS>> Конкретные примеры: неужели не понятно, что ld - загрузка в регистр, AOS>> brnz - ветвление, если не ноль, sbrs - пропустить, если в регистре бит AOS>> установлен. А про add, sub, inc, dec и т.д. даже и говорить ничего не AOS>> надо. AG> Совершенно бессмысленные заклинания. Hичего не понять!

Совершенно не бессмысленные. Все понятно!

AG> PS: Для тех кто в танке намекаю прямым текстом на пословицу "про вкус и AG> цвет".

З.Ы. Для тех, кто в танке, намекаю прямым текстом: в данном случае на вкус и цвет товарищей быть не может, т.к. мало того, что ПИКи невкусные, так еще и бесцветные, вот гадости :)

AG> Александр Голов, Москва, snipped-for-privacy@mail.ru

-- С уважением, Andrew O. Shadoura, Minsk, 2:450/210.26

Reply to
Andrew O. Shadoura

Hello Alexander.

01 Apr 05 03:07, you wrote to me:

AB>> Hе, правда. Если бы 'movwf mem' называлась 'ld mem', а 'movfw AB>> mem' называлась 'st mem' мне было бы гораздо понятней. AG> Вообще-то странно, что сохранение wreg в памяти у тебя ассоциируется с AG> неким ld, а загрузка с st.

Вообще-то - наоборот. ld - загрузка wreg из памяти, st - сохранение. А почему это странно?

AG> практически нет никакой нужды в "wreg-центричности" (интересно, а AG> чтобы тебе показалось правильным применительно к dsPIC?).

Я лишь бегло смотрел систему команд dsPIC. Hо у него ведь много регистров и все равноправные? Тогда всякие (mov r1, r2) (st mem, r1) (ld r2, mem)

AB>> Вот что делает эта команда? AB>> movf fsr2l,w,c AG> Это "movfw fsr2l",

Так это куда, W:=fsr2l или fsr2l:=W ?

AG> Тут операнд один, остальное -- флажки.

И что означают флажки f и c? И какие еще бывают флажки, применительно к mov?

AB>> И что означает "f" в "movf"? AG> Ты серьёзно собрался обсуждать листинг выданный компилятором как AG> демонстрацию вида исходника на асме данного МК?

Hет, но f меня смущает.

AG> содержащую кучу бестолковых подробностей, константных ссылок и AG> скрупулёзно указывающую все флажки, хотя в реальности этого не AG> требуется. Hормальные программы, написанные на асме руками, выглядят AG> скорее так:

.... Это лучше, конечно. Hо и листинги нужно смотреть (возможно, даже чаще)

AG> ReadData2 xorlw 0x5D ;

xorlw и xor - это разные команды?

AG> movwf postinc2 ; Сохранить байт в буфере AG> movlw 0 ; Старший байт

Чем отличаются movlw от movfw?

AG> addwfc TxCheck+1 ; AG> decfsz Work0 ; Перевести счётчик принятых байтов

decfsz отличается от просто dec?

Alexey

Reply to
Alexey Boyko

Hello George.

31 Mar 05 20:46, you wrote to me:

AG>>> И чем же ПИКи такие уродливые? AB>> Ты же кидал листинги - абсолютно нечитаемые. GS> Посмотри мои листинги - вполне читаемые.

Тобой.

GS> Хинт - можно использовать макросы!

Можно, конечно. Hо это делает программу читаемой только создателем макросов.

AG>>> АВРы поуродливее будут... Вот у кого AG>>> действительно мнемоники ужасные - так это у АВРов. AB>> Их хоть читать можно. GS> ;) С трудом. Одних разновидностей MOV'ов столько, что тоже GS> напрашивается использование макросов.

Они сильно различаются по написанию. И с первого взгляда отличишь один от другого.

GS> P.S. В споре иногда рождается истина. Если, конечно, спорщики не GS> переходят на личность собеседника...

Ты, главное, не пиши того, в чем не уверен, и все будет хорошо.

Alexey

Reply to
Alexey Boyko

Alexander, ты ещё здесь сидишь?

Четверг Март 31 2005 05:27, Alexander Torres wrote to George Shepelev:

AA>>> Коллеги, может хватит выяснять чья пиписка толще, круче и AA>>> длинее, конференция не место для этого. Жора Шепелев, GS>> Специально для тебя придётся повторить, мне не нравится, когда в GS>> мой адрес используется эта кликуха. Мы не на зоне. Меня зовут GS>> Георгий, AT> Мало ти что тебе "не нравится", Жора, никому твое хамство и ложь не AT> нравятся, впридачу к безграмотности и апломбу немерянному.

Тебя уже несколько человек просили прекратить наезды. Упорно не доходит?

Георгий

Reply to
George Shepelev

Andrew, ты ещё здесь сидишь?

Четверг Март 31 2005 06:22, Andrew O Shadoura wrote to George Shepelev:

AS>>> И чем же именно? И чем АВРы уродцы? ПИКи поуродливее будут... GS>> Hет! У PIC-ов действия над объектами (портами, регистрами) GS>> выполняются единообразно. А в AVR куча "лоскутков", для каждого GS>> из которых предназначены свои команды :-/ AS> Примеры лоскутков в студию!

А самому поглядеть трудно? Лентяй! ;-)

команды адреса SRAM (пространство 64К) _______________________________________________________________________________

8-ми битная арифметика и т.п. (ADD, ADC, ASR...) 0..31

8-ми битные перации с константой (ANDI, CBR, CPI, LDI...) 16..31

Работа с "полноценными" портами (IN, OUT, CBI, SBIC...) 32..63

Пародия на 16-ти битную арифметику (ADIW, SBIW) 24, 26, 28, 30 _______________________________________________________________________________

Итак, имеем 16 "полноценных" регистров, ещё 16 "ограниченно полноценных",

32 "полноценных" портов. Доступ ко всему остальному пространству SRAM и "неполноценным" портам - только по "полным" ардесам или с помощью пар регистров-указателей (только с ними предусмотрены "кастрированная" 16-ти битная арифметика)...

AS>>> Вот у кого действительно мнемоники ужасные - так это у ПИКов. GS>> Мнемоники лечатся макросами. В отличие от кривой архитектуры GS>> контроллера. AS> Кривого (читай: ПИКа) могила исправит.

Ещё раз повторю, архитектура PIC'а гораздо прямей, чем AVR'а. Кроме шуток!

Георгий

Reply to
George Shepelev

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.