|
Виж темите без отговор | Виж активните теми
Дата и час: Вто Юли 28, 2026 12:41 am
C за PIC18, използващо хардуерното му умножение?
| Автор |
Съобщение |
|
sparkybg
Ранг: Форумен бог
Регистриран на: Вто Авг 23, 2005 12:02 pm
Мнения: 3070
Местоположение: София
|
 C за PIC18, използващо хардуерното му умножение? ...после що съм ползвал 32 битници където трябва и където не... Ако пуснат 5 волтов, тотално ще забравя за всичко друго... Та - на въпроса: Има ли някакъв компилатор някъде, дето да ползва това хардуерно умножеине за нещо повече от 8 битови числа? И да работи под MPLAB X? XC8, последна версия, използва хардуерно умножение само за 8 битови числа без знак. Hi-Tеch C18 9.80 - пак така. За останалото си вика подпрограмка, дето го прави с цикли като на PIC16. Вече окончателно се убеждавам че във всички фирми, започващи с "micro" изначално има нещо недоклатено.  Сега го правя по изкуствен начин, умножавайки байт по байт и събирайки. Трябва ми умножение 16 x 16 бита, резултата от което се записва в 32 битова променлива. Не ми е проблем и така, ама кода за едно мижаво умножение е 6-7 реда, и ако го чета след някоя и друга година, има да се дзверя доста.
|
| Сря Яну 30, 2013 10:13 pm |
 
|
|
|
FiTTiLA
Ранг: Професионалист
Регистриран на: Сря Май 11, 2005 3:47 pm
Мнения: 534
|
Re: C за PIC18, използващо хардуерното му умножение? С константа ли умножаваш? Ако да, използвай Хорнер метода на асемблер, събиране-изваждане-шифтване ... ако не го ползваш вече !
|
| Чет Яну 31, 2013 3:22 pm |
|
|
|
sparkybg
Ранг: Форумен бог
Регистриран на: Вто Авг 23, 2005 12:02 pm
Мнения: 3070
Местоположение: София
|
Re: C за PIC18, използващо хардуерното му умножение? С константа умножавам, 16 битова. И е голямо число, примерно 38342. С шифтване и баба знае, ама тогава за какво да ползвам PIC18? То хардуерното му умножение е съществената разлика с 16-ките. Сега го правя с четири 8 битови умножения и 4 събирания. Ама просто умножение се мъдри на 6-7 реда, ползват се буферни променливи и прочие. Ако си е вградено в компилатора ще е доста по-оптимизирано, а в сорса ще си е просто c=a*b. На асемблер е лесно, ама да уча асемблер за 8 битов PIC - айде мерси. Въпроса е че микрочЕп пак са се изсрали на метеното - сътворили микроконтролер с хардуерно умножение за един цикъл, пък не го ползват. И едно умножение 16x16 отива примерно 100 и повече цикъла. dsPIC30 например си има макроси, дето му ползват дори 30 битовия (или 40 беше) акумулатор, а за 18-ката - нищо.
|
| Чет Яну 31, 2013 3:36 pm |
|
|
|
tgi
Ранг: Форумен бог
Регистриран на: Нед Юни 10, 2007 2:22 pm
Мнения: 6492
Местоположение: София
|
Re: C за PIC18, използващо хардуерното му умножение? Е чак да му "учиш асемблера" за да си направиш умножението едва ли ще ти се
наложи де (ама и цял ден като нищо може да ти отиде да се справиш).
Инак 16*16->32 умножение ако нямаш наготово какво друго ти остава освен както
си го направил с 8*8->16 но на асемблер. Все пак са само няколко реда, десетки
реда да са. 1*1->2 ("със събиране и шифтване", което е същото като 8*8-> 16
и останалите де) ще е много по-неефикасно по всяка вероятност (е, зависи колко
време цъка 8*8, на баба 9-ка (6809) на времето това май беше 11 цикъла... Ама тя
поне си имаше нормален стек и с офсети от него та ставаше лесно).
Моят плач е най-вече с делението, почти за всяко ядро ми се е налагало да го
правя (дори за power, 32 битовите нямат 64:32 -> 32(или overflow) като CPU32...
Всъщност за CPU32 май не се наложи, за HC11 не помня, май не - там имаше
и fractional divide ли някакво беше та ставаше каквото ми е трябвало май.
_________________------------------- www.tgi-sci.com------------------- http://www.flickr.com/photos/didi_tgi/
|
| Пет Фев 01, 2013 1:38 am |
|
|
|
sparkybg
Ранг: Форумен бог
Регистриран на: Вто Авг 23, 2005 12:02 pm
Мнения: 3070
Местоположение: София
|
Re: C за PIC18, използващо хардуерното му умножение? 8*8->16 хардуерното умножение на PIC18 е един цикъл. 4 умножения със все събиранията, написани на C са 30-ина цикъла. На асемблер може и по-малко.
...ама, не мога бре човек. Някога пишех тонове асемблер за 80386. За 8051 някак пак се справях, ама в пикльовците всичко ми е наопъки. А и да уча асемблер за 8, 16 и 32 битови пикльовци, дето нямат нищо общо, пак не ми е никак комфортно. Сложи и RX серията на Renesas, с която също се заигравам, и мазалото става пълно.
Конкретното нещо, за което ползвам 18-ката, не е критично по отношение на това. Предполагаемо и с обикновените библиотеки, дето правят същото за примерно 200 цикъла, пак няма да има грижи. Просто питах дали има някакъв вариант. Дали някое от всичките C-та за тоя процесор поддържа това. И да вика подпрограма не ми пречи, стига подпрограмата да ползва хардуерното умножение.
|
| Пет Фев 01, 2013 2:13 am |
|
|
|
tgi
Ранг: Форумен бог
Регистриран на: Нед Юни 10, 2007 2:22 pm
Мнения: 6492
Местоположение: София
|
Re: C за PIC18, използващо хардуерното му умножение? Е щом не ти трябва ясно, че няма цял ден да го мъчиш. Инак едва ли би те озорило, щом на кривия x86 асемблер си писал коя е тая кривотия дето ще те уплаши  . Специално за няколкото реда дето ти трябват ти е ясно, че не трябва да му свикваш на дадения асемблер, би ги написал с книжката в ръцете (правил съм го за x86 за не много по-сложно нещо, стана за час-два - преди много години, това ми е писането за x86 ). Ама за едното по-добро чувство ако имам работещ код не бих го пипал на твое място и аз. Тогава, на времето, като писах това за x86, един се беше уплел дни наред да изшифти няколко бита към един четворен DAC, мажеше нещо на някакво турбо-C май беше (не то беше проблемът разбира се) та на края ми писна и го разплетох набързо; после той някак успя поне асемблерския сорс да навре в C сорса си, за толкова му стигна акъла... . А аз май го пишех на ръка и го дебъчех в някакъв AFD дебъгер май дето имаше. Баси колко години от тогава, над 20. Сякаш беше миналата седмица. _________________------------------- www.tgi-sci.com------------------- http://www.flickr.com/photos/didi_tgi/
|
| Пет Фев 01, 2013 3:22 am |
|
|
|
sparkybg
Ранг: Форумен бог
Регистриран на: Вто Авг 23, 2005 12:02 pm
Мнения: 3070
Местоположение: София
|
Re: C за PIC18, използващо хардуерното му умножение? За x86 съм писал DOS extender за защитен режим, бях изкормил и едно C и му бях подменил библиотеките да ползва моя Extender. Вървеше и под Windows 95. Бях писал библиотеки за 3D графики, текстури, шейдинг и прочие полюции. Всичко на асемблер. И това докато не изкараха първите версии на SIMD разширенията. Тогава се и обезсмисли всякакво ровене в тая посока, щото на мода дойде хардуерното ускорение.
Та, оня асемблер ми е по-логичен. Имаш 8+4 регистъра, някои със специфично предназначение, и толкоз. И командите прости - MOV AX, BX, означава "сложи съдържанието на BX в AX". И всичките в тоя вид - с 2 операнда (с малки изключения). Тук всичко е обратно - там jump, тука branch. Тук и NOP-ове трябва да се оставят тук-там. Там имаше shift-ове по колкото се сетиш позиции с една инструкция, тука - не. И все такива.
Там имаше и делене 16/8 ->8, 32/16 -> 16, 64/32 ->32.
Незнам. Сигурно ако много ми дотрябва ще се счупя да го понауча. Ама ми е изчекнат и туй то. На PIC32-ката е малко по-човешки като че ли. На RX-а хич не съм го и гледал още. Но помня че на 8051 общо взето се справях без особен зор за дребни неща.
Най-вероятно съм поръждясал, и додето не ми дойде съвсем на зор, трудно ще се счупя.
|
| Пет Фев 01, 2013 3:40 am |
|
|
|
palavrov
Ранг: Форумен бог
Регистриран на: Вто Окт 11, 2011 11:53 pm
Мнения: 4582
Местоположение: Brussels / Пловдив
|
Re: C за PIC18, използващо хардуерното му умножение? В AFD май си имаше вграден асемблер ... колко нощи само с дебъгвал с него ... игрици, пък и не само ... накрая си написах сам дебъгер, супер стелт и запазваше графичните режими като хората ... извинявам се за оффтопика
_________________
Мразя да мразя ...
|
| Пет Фев 01, 2013 4:37 am |
|
|
|
¶
Ранг: Форумен бог
Регистриран на: Пет Фев 25, 2005 1:58 pm
Мнения: 4585
Местоположение: US
|
Re: C за PIC18, използващо хардуерното му умножение? MPLABX 1.60, MCC18 v3.43, Windows/Linux Project option: C18(Global Options)/MCC18/Default Storage Class: StaticSmall memory model | | | | Код: !void main(void) {
!volatile near int a,b;
!volatile near long c;
! a = 38342;
0xA6: MOVLW 0xC6
0xA8: MOVWF a, ACCESS
0xAA: MOVLW 0x95
0xAC: MOVWF 0x1, ACCESS
! b = -30342;
0xAE: MOVLW 0x7A
0xB0: MOVWF b, ACCESS
0xB2: MOVLW 0x89
0xB4: MOVWF 0x3, ACCESS
! c = a * b;
0xB6: MOVF b, W, ACCESS
0xB8: MULWF a, ACCESS
0xBA: MOVFF PRODL, c
0xBC: NOP
0xBE: MOVFF PRODH, 0x5
0xC0: NOP
0xC2: MULWF 0x1, ACCESS
0xC4: MOVF PRODL, W, ACCESS
0xC6: ADDWF 0x5, F, ACCESS
0xC8: MOVF 0x3, W, ACCESS
0xCA: MULWF a, ACCESS
0xCC: MOVF PRODL, W, ACCESS
0xCE: ADDWF 0x5, F, ACCESS
0xD0: CLRF 0x6, ACCESS
0xD2: CLRF 0x7, ACCESS
0xD4: BTFSS 0x5, 7, ACCESS
0xD6: BRA 0xDC
0xD8: SETF 0x6, ACCESS
0xDA: SETF 0x7, ACCESS
! while(1);
0xDC: BRA 0xDC
| | | | |
Project option: C18(Global Options)/MCC18/Default Storage Class: StaticLarge memory model | | | | Код: !void main(void) {
!volatile int a,b;
!volatile long c;
! a = 38342;
0xA6: MOVLB 0xE
0xA8: MOVLW 0xC6
0xAA: MOVWF 0xA, BANKED
0xAC: MOVLW 0x95
0xAE: MOVWF 0xB, BANKED
! b = -30342;
0xB0: MOVLW 0x7A
0xB2: MOVWF 0xC, BANKED
0xB4: MOVLW 0x89
0xB6: MOVWF 0xD, BANKED
! c = a * b;
0xB8: MOVF 0xC, W, BANKED
0xBA: MULWF 0xA, BANKED
0xBC: MOVFF PRODL, c
0xBE: NOP
0xC0: MOVFF PRODH, 0xE0F
0xC2: NOP
0xC4: MULWF 0xB, BANKED
0xC6: MOVF PRODL, W, ACCESS
0xC8: ADDWF 0xF, F, BANKED
0xCA: MOVF 0xD, W, BANKED
0xCC: MULWF 0xA, BANKED
0xCE: MOVF PRODL, W, ACCESS
0xD0: ADDWF 0xF, F, BANKED
0xD2: CLRF 0x10, BANKED
0xD4: CLRF 0x11, BANKED
0xD6: BTFSS 0xF, 7, BANKED
0xD8: BRA 0xDE
0xDA: SETF 0x10, BANKED
0xDC: SETF 0x11, BANKED
! while(1);
0xDE: BRA 0xDE
| | | | |
Project option: C18(Global Options)/MCC18/Default Storage Class: AutoSmall memory model | | | | Код: !void main(void) {
0xA6: MOVFF FSR2L, POSTINC1
0xA8: NOP
0xAA: MOVFF FSR1L, FSR2L
0xAC: NOP
!volatile int a,b;
!volatile long c;
! a = 38342;
0xAE: MOVFF FSR1L, FSR0L
0xB0: NOP
0xB2: MOVFF FSR2H, FSR0H
0xB4: NOP
0xB6: MOVLW 0xC6
0xB8: MOVWF POSTINC0, ACCESS
0xBA: MOVLW 0x95
0xBC: MOVWF POSTDEC0, ACCESS
! b = -30342;
0xBE: MOVF FSR2L, W, ACCESS
0xC0: ADDLW 0x2
0xC2: MOVWF FSR0L, ACCESS
0xC4: MOVFF FSR2H, FSR0H
0xC6: NOP
0xC8: MOVLW 0x7A
0xCA: MOVWF POSTINC0, ACCESS
0xCC: MOVLW 0x89
0xCE: MOVWF POSTDEC0, ACCESS
! c = a * b;
0xD0: MOVFF FSR2L, FSR0L
0xD2: NOP
0xD4: MOVFF FSR2H, FSR0H
0xD6: NOP
0xD8: MOVFF POSTINC0, c
0xDA: NOP
0xDC: MOVFF INDF0, 0x5
0xDE: NOP
0xE0: MOVF FSR2L, W, ACCESS
0xE2: ADDLW 0x2
0xE4: MOVWF FSR0L, ACCESS
0xE6: MOVFF FSR2H, FSR0H
0xE8: NOP
0xEA: MOVFF POSTINC0, 0x6
0xEC: NOP
0xEE: MOVFF INDF0, 0x7
0xF0: NOP
0xF2: MOVF 0x6, W, ACCESS
0xF4: MULWF c, ACCESS
0xF6: MOVFF PRODL, __tmp_0
0xF8: NOP
0xFA: MOVFF PRODH, 0x1
0xFC: NOP
0xFE: MULWF 0x5, ACCESS
0x100: MOVF PRODL, W, ACCESS
0x102: ADDWF 0x1, F, ACCESS
0x104: MOVF 0x7, W, ACCESS
0x106: MULWF c, ACCESS
0x108: MOVF PRODL, W, ACCESS
0x10A: ADDWF 0x1, F, ACCESS
0x10C: CLRF b, ACCESS
0x10E: CLRF 0x3, ACCESS
0x110: BTFSS 0x1, 7, ACCESS
0x112: BRA 0x118
0x114: SETF b, ACCESS
0x116: SETF 0x3, ACCESS
0x118: MOVF FSR2L, W, ACCESS
0x11A: ADDLW 0x4
0x11C: MOVWF FSR0L, ACCESS
0x11E: MOVFF FSR2H, FSR0H
0x120: NOP
0x122: MOVFF __tmp_0, POSTINC0
0x124: NOP
0x126: MOVFF 0x1, POSTINC0
0x128: NOP
0x12A: MOVFF b, POSTINC0
0x12C: NOP
0x12E: MOVFF 0x3, POSTINC0
0x130: NOP
! while(1);
0x132: BRA 0x132
| | | | |
Project option: C18(Global Options)/MCC18/Default Storage Class: AutoLarge memory model | | | | Код: !void main(void) {
0xA6: MOVFF FSR2L, POSTINC1
0xA8: NOP
0xAA: MOVFF FSR1L, FSR2L
0xAC: NOP
0xAE: MOVLW 0x8
0xB0: ADDWF FSR1L, F, ACCESS
!volatile int a,b;
!volatile long c;
! a = 38342;
0xB2: MOVLW 0xC6
0xB4: MOVWF POSTINC2, ACCESS
0xB6: MOVLW 0x95
0xB8: MOVWF POSTDEC2, ACCESS
! b = -30342;
0xBA: MOVLW 0x7A
0xBC: MOVWF PRODL, ACCESS
0xBE: MOVLW 0x2
0xC0: MOVFF PRODL, PLUSW2
0xC2: NOP
0xC4: MOVLW 0x89
0xC6: MOVWF PRODL, ACCESS
0xC8: MOVLW 0x3
0xCA: MOVFF PRODL, PLUSW2
0xCC: NOP
! c = a * b;
0xCE: MOVLW 0x2
0xD0: MOVFF PLUSW2, 0x8
0xD2: NOP
0xD4: MOVLW 0x3
0xD6: MOVFF PLUSW2, 0x9
0xD8: NOP
0xDA: MOVFF POSTINC2, 0xD
0xDC: NOP
0xDE: MOVFF POSTDEC2, 0xE
0xE0: NOP
0xE2: CALL 0x114, 0
0xE4: NOP
0xE6: MOVFF 0x6, __tmp_0
0xE8: NOP
0xEA: MOVFF 0x7, 0x15
0xEC: NOP
0xEE: CLRF 0x16, ACCESS
0xF0: CLRF 0x17, ACCESS
0xF2: BTFSS 0x15, 7, ACCESS
0xF4: BRA 0xFA
0xF6: SETF 0x16, ACCESS
0xF8: SETF 0x17, ACCESS
0xFA: MOVLW 0x4
0xFC: MOVFF __tmp_0, PLUSW2
0xFE: NOP
0x100: MOVLW 0x5
0x102: MOVFF 0x15, PLUSW2
0x104: NOP
0x106: MOVLW 0x6
0x108: MOVFF 0x16, PLUSW2
0x10A: NOP
0x10C: MOVLW 0x7
0x10E: MOVFF 0x17, PLUSW2
0x110: NOP
! while(1);
0x112: BRA 0x112
| | | | |
Все пак не очаквай, че като има хардуерен множител ще умножи две 16-битови числа с няколко инструкции, прочети какво вършат MULLW и MULWF и ще разбреш защо е така.
_________________
Ето аз дишам, работя, живея и програми пиша тъй както умея, с проца под вежди се гледаме строго и боря се с него доколкото мога....
Последна промяна ¶ на Пет Фев 01, 2013 6:38 am, променена общо 2 пъти
|
| Пет Фев 01, 2013 6:21 am |
|
|
|
tgi
Ранг: Форумен бог
Регистриран на: Нед Юни 10, 2007 2:22 pm
Мнения: 6492
Местоположение: София
|
Re: C за PIC18, използващо хардуерното му умножение? Е, тоя вид ръжда се смива за нула време при нужда, нищо ти няма. Но да се връща назад човек по езиците към по-криви такива е наистина болезнено, дори да не става дума за пик асемблер. Тоя за 32 е MIPS който по принцип е добра архитектура но пък наличните RISC асемблери са пълна трагедия като мнемоники, x86 дори е доста по-човешки (а той по моите критерии е неизползваемо крив, аз съм разглезен на 68k и сега на VPA). Та нямаш много опции де, аз VPA-то на практика не го предлагам а и го има само за power така или иначе. Ама за едното умножение да си съшиеш няма да имаш нужда и ръждата да махаш, това имах предвид. Е аз асемблирах с тоя AFD-чавия асемблер де, не "на ръка". То стана и доста бързо, все пак колко е да нашифтиш 4 DAC-а. На хартия на ръка съм асемблирал само за 6800 и малко за 6809. _________________------------------- www.tgi-sci.com------------------- http://www.flickr.com/photos/didi_tgi/
|
| Пет Фев 01, 2013 6:23 am |
|
|
|
¶
Ранг: Форумен бог
Регистриран на: Пет Фев 25, 2005 1:58 pm
Мнения: 4585
Местоположение: US
|
Re: C за PIC18, използващо хардуерното му умножение? На MIPS мнемониката на асемблера им е най-малкия проблем - винаги можеш да си я замениш с твоя си посредством макроси. По скоро проблема е, че в почти всяка инструкция адресацията се задава с отместване, което явно трябва да се зададе, дори и да е 0. Поне мен това страшно ме обърква и в един момент реших, че не си заслужава да им уча асемблера. Виж на dsPIC30/33 го научих лесно, щото е доста сносно направен.
_________________
Ето аз дишам, работя, живея и програми пиша тъй както умея, с проца под вежди се гледаме строго и боря се с него доколкото мога....
|
| Пет Фев 01, 2013 9:05 am |
|
|
|
sparkybg
Ранг: Форумен бог
Регистриран на: Вто Авг 23, 2005 12:02 pm
Мнения: 3070
Местоположение: София
|
Re: C за PIC18, използващо хардуерното му умножение? Мерси. Четох какво вършат. То ясно че освен умноженията трябва и друго, ама едно е 230 цикъла, друго е 30. Сега ще видя от къде да сваля някое от тия C-та.
|
| Пет Фев 01, 2013 11:06 am |
|
|
|
rumen65
Ранг: Новодошъл
Регистриран на: Чет Окт 06, 2005 2:06 pm
Мнения: 194
Местоположение: Sofia
|
Re: C за PIC18, използващо хардуерното му умножение?
|
| Пет Фев 01, 2013 12:32 pm |
|
|
|
sparkybg
Ранг: Форумен бог
Регистриран на: Вто Авг 23, 2005 12:02 pm
Мнения: 3070
Местоположение: София
|
Re: C за PIC18, използващо хардуерното му умножение? Свалих и инсталирах квото трябва вече. От рутракера.
|
| Пет Фев 01, 2013 12:47 pm |
|
|
|
tgi
Ранг: Форумен бог
Регистриран на: Нед Юни 10, 2007 2:22 pm
Мнения: 6492
Местоположение: София
|
Re: C за PIC18, използващо хардуерното му умножение? Да, аз като казах мнемоники имах предвид целия синтаксис. То и за power е същата работа, не може човек да пише много на такова нещо. Освен всичко друго - примерно различни имена на опкодове за същата операция с различен размер вместо .b, .w, .l и т.н. - нали са и load/store системи та операциите са само между регистри, и това да го описва човек идва вповече. Адресациите и те - нали са малко на брой, намацали ги в различни по име опкодове и айде. VPA-то се справя с всичко това - ама ми отне почти година да го направя и да прехвърля кода за cpu32 да тръгне на power, баси и оттогава има над 10 години, кво става бе. Днес сме тук утре пак ни няма, това е положението . _________________------------------- www.tgi-sci.com------------------- http://www.flickr.com/photos/didi_tgi/
|
| Пет Фев 01, 2013 1:55 pm |
|
|
Кой е на линия |
Потребители разглеждащи този форум: 0 регистрирани и 1 госта |
|
Вие не можете да пускате нови теми
Вие не можете да отговаряте на теми
Вие не можете да променяте собственото си мнение
Вие не можете да изтривате собствените си мнения
Вие не можете да прикачвате файл
|
|
