[ megoldva] gpasm ami free

Egyéb: Assembly, Ada...

Itt szívok fél napja! 


mpasm - ez ingyenes, de sok hibája van
  000009C3            00045 PERIOD_3        equ             P_25600
020D   3009           00048                 movlw           high PERIOD_3

gpasm - ez free és javítja az mpasm hibáit
  000009C3            00045 PERIOD_3        equ             P_25600
020D   3089                  00048          movlw           high PERIOD_3

Most jön az abakusz programozói tanfolyam. :(

  • 4770 megtekintés

( Szenti v | 2014. 09. 25., cs – 13:50 )

Nem teljesen világos, hogy mit szeretnél.

( martonmiklos v | 2014. 09. 25., cs – 14:27 )

A nyugodt élet egyik titka, hogy kerülöd azon cégek termékeit amiben szerepel a "micro" szó.

( 4fonya | 2014. 09. 25., cs – 16:06 )

Lássuk csak: 


gpasm-1.3.0 #1100 (Sep 15 2014) ./src/main.as   9-25-2014  16:03:10         PAGE  1

.
.
.

  000009C3            00006 PERIOD_3        equ     2499
                      00007 
                      00008         code
                      00009 
0000   3009           00010         movlw   high PERIOD_3

Milyen gpasm változattal próbáltad?

Furcsa. Direkt az ősrégi PIC16F84-el próbáltam és azt az eredmény produkálta amit a válaszomban látsz. Minden svn commit előtt tesztelem a programokat és nem teszek közzé olyat ami hibát vét.

A gputils jelenleg itt tart:
gputils-20140915-1101-setup.exe
gputils-src-20140915-1101.tar.gz

3089 :(
Tényleg furcsa. Még tovább megyek: PIC16F1789 a próbálkozás tárgya.
Az előző PIC18F2550 volt. Az előbbi következetesen téveszt, az utóbbi meg jó.

Az equ, high, low, +, -, stb. csak "számológép". Ha bármilyen függősége van a high
direktívának, akkor most kellene eltávolítani.

Nálam jó: 


gpasm-1.3.0 #1100 (Sep 15 2014) ./src/main.as   9-26-2014  08:16:31         PAGE  1


LOC    OBJECT CODE    LINE  SOURCE TEXT
  VALUE

                      00001 
                      00002         list p=16f1789
                      00003         radix dec
                      00004         include p16f1789.inc
                      00001         LIST
                      00002 
                      00003 ;==========================================================================
                      00004 ; Build date : Aug 07 2014
                      00005 ;  MPASM PIC16F1789 processor include
                      00006 ; 
                      00007 ;  (c) Copyright 1999-2014 Microchip Technology, All rights reserved
                      00008 ;==========================================================================
                      00009 
                      03205         LIST
                      00005 
  000009C3            00006 PERIOD_3        equ     2499
                      00007 
                      00008         code
                      00009 
0000   30C3           00010         movlw   low PERIOD_3
0001   3009           00011         movlw   high PERIOD_3
0002   2???           00012         goto    $
                      00013 
                      00014         end
gpasm-1.3.0 #1100 (Sep 15 2014) ./src/main.as   9-26-2014  08:16:31         PAGE  2

---------------------------------------------

Ennek utána kell járni. Nálam Fedora 20 x86_64 fut. Te milyen rendszeren és milyen programmal kisérleteztél? (gpasm -v)

A P_25600 értéke hogyan áll elő?

( locsemege v | 2014. 09. 26., p – 00:31 )

Esetleg így?

movlw PERIOD_3 >> 8 & 0xff

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( 4fonya | 2014. 09. 26., p – 09:27 )

Akkor nem áll elő a hiba ha előbb object kódot fordítasz és a gplink készíti el a hex-et. Ha viszont egyetlen modulból áll a program és a gpasm önállóan készít hex-et akkor azonnal előjön a hiba: 


gpasm-1.3.0 #1100 (Sep 15 2014) ./test/main.a   9-26-2014  09:17:21         PAGE  1


LOC    OBJECT CODE    LINE  SOURCE TEXT
  VALUE

                      00001 
                      00002         list p=16f1789
                      00003         radix dec
                      00004         include p16f1789.inc
                      00001         LIST
                      00002 
                      00003 ;==========================================================================
                      00004 ; Build date : Aug 07 2014
                      00005 ;  MPASM PIC16F1789 processor include
                      00006 ; 
                      00007 ;  (c) Copyright 1999-2014 Microchip Technology, All rights reserved
                      00008 ;==========================================================================
                      00009 
                      03205         LIST
                      00005 
  000009C3            00006 PERIOD_3        equ     2499
                      00007 
0000   30C3           00008         movlw   low PERIOD_3
0001   3089           00009         movlw   high PERIOD_3
                      00010 
0002   3009           00011         movlw   PERIOD_3 >> 8 & 0xFF
0003   2803           00012         goto    $
                      00013 
                      00014         end

-------------------------------------------

Ez bizony hiba a fordítóban, nekiállok megkeresni. Úgy látszik hogy az eddig használt tesztek "lyukasak". Csodálom hogy eddig még senki sem jelezte.

Addig is áthidaló javaslatként azt ajánlom hogy a gpasm-al készíttess object kódot és a gplink segítségével állítsd elő a kész - hex - kódot.

Egy régebbi kódrészlet okozta a hibát és csak a fejlettebb 14 bites PIC családban, akkor is csak abszolút módban (tehát amikor a gpasm közvetlenül készít hex-et). Már kijavítottam és most tesztelem. Csak azon csodálkozom hogy ez eddig senkinek sem szúrt szemet. Nem volt bugreport. Ami azt jelenti hogy legalább egy éve így van. (Most nincs kedvem megnézni hogy melyik elődöm módosította ezt a részt utoljára.)

-------------------------------------

Itt van a gyógyszer:
gputils-src-20140926-1102.tar.gz
gputils-20140926-1102-setup.exe

"Patch érdekelt volna, hogy látszódjék a hiba."

Ez a lényeg, tessék. (Még a megjegyzés is hibás volt: "if var type is GVT_CBLOCK return 1, else return 0")

"Hogyan fognak értesülni a disztribútorok erről?"

Úgy hogy egyszer majd (remélem hogy nem sokára) kiadok egy végleges csomagot gputils-1.4.0 néven. A mostani (svn #1102) még csak egy fejlesztői változat. Amúgy érdemes lenne megnézned hogy egyes disztribúciók - élen a Debiannal - milyen elképesztően le vannak maradva. A Debian még mindig a gputils-0.13.7-1 változatnál tart. Nevetséges. Az Ubuntu sem különb.

"A fedorás csomagot te tartod karban?"

A gputils csomag karbantartója a Fedora package db szerint "rrankin". A név alapján gyanakszom arra hogy Roy Rankin lehet, mivel a gpsim csomag egyik fejlesztőjének levélcíme a ChangeLog alapján: Roy Rankin <rrankin@ihug.com.au>

Eszerint a Fedora 21 előzetesben a gputils-1.3.0 van benne, ez az amit tavasszal adtam ki.

Egy beágyazott (ARM) fejlesztés alkalmával jöttem rá hogy egy "return (valami0 == valami1);" nem feltétlenül azt csinálja amit szeretnék. Csak akkor volt jó ha így írtam le: "return ((valami0 == valami1) ? true : false);" (A true természetesen 1, a false pedig 0, a függvény pedig egészet (int) ad vissza.) Azóta rászoktam erre az írásmódra.

Köszi a gyors javítást!
Azért egyet nem értek. A high operátor, ezért platformfüggetlennek kellene lennie.
Szóval kényszerképzetemben, ha a tripla bájt tb=010203, akkor a high 02 értéket ad vissza.
Így a
movlw high(tb)
és a
movlw 2
azonos kódot eredményez.

Ez olyan, mint a zsebszámológép, amely az egységárból úgy képzi a 2kg árát, hogy a só árát megszorozza 2, a cukor árát meg 3 értékkel, mert az cukor. :)
Szóval a cím korrekciójára nem lenne szabad egy operátor működését (néha) megváltoztatni.

PIC-eknél nem olyan egyszerű ez. Egyfelől ugyanaz a fordító egy rakás processzorra fordít, amelyek hasonlók, de nem teljesen kompatibilisek. Másfelől az operanus is változó hosszúságú: fileregister címzésekor 7 bit szokott lenni, 1 bit a cél helye, literálisnál 8 bit a szokásos, de ugrásnál ez is hosszabb jellemzően.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

2.2.2 Expressions
The gpasm expressions are implemented using 32-bit arithmetic. gpasm supports a full set of operators,
based on the C operator set.
...
HIGH = high byte
Tehát a high eredménye egy 8 bites konstans. (Ráadásul konstansból keletkezett.)
A movlw 8 bites regiszterbe tölt be egy konstanst.
Ha a betöltendő adat hosszabb, akkor a fordító sikít.

Azaz nullától végtelen bitszámig a high az izének a 8..15 bitjét jelenti. Ha típusosan néznénk, akkor a high akármiből konstanst csinál, és itt vége az okoskodásnak. A konstanst nem szabad tovább értelmezni, mert puszta szám.

Ezért nem az a hiba, hogy rossz helyen van az if, hanem hogyan keveredik oda a fordító, hogy egy művelet konstans végeredményéről elkezdi latolgatni, hogy lehet-e cím?

De bizony, ott volt. Az mplabx-el való kompatibilitás lehet az oka. Az mpasmx-el csináltam meg az ellenpróbát és emiatt a gpasm tesztek közé is fölvettem két példa asm-ot.

------------------------------

Egyébként arra készülök hogy valamikor a hét végén kiadom a gputils-1.4.0-RC1-et. A tavasz óta sok változás történt úgy hogy itt lesz az ideje.