Pratar Assembler. Vill lära mig nytt språk..

[eqlazer]

Finns många sätt att göra samma sak, tex:

Kod: Markera allt

#define PINB 0x1234
#define PB7 7

if( !(PINB & (1<<PB7)) )

[ElectricNooB]

Det där tar dock olika mycket tid beroende på vilken bit som avses. Detta kan leda till huvudvärk vid tex. "bitbanging"...

[kvaark]

Det är typ bitbamging jag ska göra, kolla bit 7 utföra åtgärden sedan skifta till vänster och upprepa 7 gåner!

Edit: 7 istf 8
Edit1: stavning

[Lennart Aspenryd]

Om man vill lära sig ett nytt språk skall man nog ta ett som kanske har framtiden för sig.
Kan "Rust" vara något? http://en.wikipedia.org/wiki/Rust_(prog ... _language)
Läs gärna på och se vad som har tagits med från andra äldre och bra språk!

Här tar man del http://www.rust-lang.org/

[ElectricNooB]

kvaark: Jag brukar göra så att jag tar if satsen jag visade tidigare och sedan så låter man bitväljarvariabeln multipliceras (eller divideras beroende på MSB/LSB) med två för att välja nästa bit. Om man använder << operatorer så blir det lite skevt vilket kan ställa till det i vissa fall...

[sodjan]

> Det är typ bitbamging jag ska göra...

Ofta fixas det med en kompakt ASM rutin som man kan anropa (t.ex från C).

> kolla bit 7 utföra åtgärden sedan skifta till vänster och upprepa 7 gåner!

Lite beroende på processormodell, men i många fall är det enklast
att använda en shift eller rotate "through carry" och testa C flaggan.

[adent]

Det där tar dock olika mycket tid beroende på vilken bit som avses. Detta kan leda till huvudvärk vid tex. "bitbanging"...

Hmm, bör inte kompilatorn inse att (1<<PB7) är konstant och räkna ut det i compile time?
Den kompilatorn jag jobbar med på jobbet gör det i alla fall. På så vis kan man skriva tydligare kod
genom att faktiskt skriva in sin beräkning (baserad på konstanter) istället för ett färdiguträknat konstant värde.

Hittade detta: http://en.wikipedia.org/wiki/Constant_folding

MVH: Mikael

[ElectricNooB]

Mycket möjligt att de dyrare gör det. Jag har dock fått väldigt lustiga bilder på mitt oscilloskop så gratis compilers fuckar upp rätt hårt i det avsendet. Jag tror det var HI-TECH C jag använde.

Sen så kan man ju fråga sig om det är värt risken att använda shift operationer som fungerar med en compiler men inte med en annan...
Skriver man open source så skall man nog ha det i bakhuvudet iaf.

ha'et

[Icecap]

Följande kommer att utföras på ett konstant sätt:

Kod: Markera allt

#define PINB 0x1234
#define PB7 7

if(!(PINB & (1<<PB7)))

Om kompilern kommer att skifta en '1' 7 gg under programkörningen ska den kompiler inte användas alls!

Detta kommer att utföras som:
if(!(PINB & 0x80))

Men

Kod: Markera allt

#define PINB 0x1234
unsigned char PB7;
PB7 = 7;
if(!(PINB & (1<<PB7)))

kommer att bli en del kod där den rent faktisk shiftar bit'en innan andningen.

Vad en del personer gör av fel är t.ex.

Kod: Markera allt

#define PINB 0x1234
#define PB7 7

if((PINB & (1<<PB7)) == 1)

Själva if()-satsen kan mycket gå väl eller fel, helt utan att kompilern gör fel! Och allt beror på brist på kunnighet i C.
Förklaring:
PINB & 0x80 kan ge 0x00 eller 0x80 som svar, inget annat. Vissa µC medger bit-adressering och då kan man testa en viss bit som '0' eller '1' men i en del fall medför detta att kompilern rent faktisk kollar om 0x00 eller 0x080 är lika med 0x01 (vilket det aldrig är) och i andra fall kan kompilern shifta bits i svaret så att en jämförelse kan fungera. Ingen av sätten är fel, osäkerheten beror på programmörens fel.

Lösningen är att sluta göra bort sig och istället använda sig av C-standardens definition:
* Allt annat än falskt är sant.
* 0x00 är alltid falskt. Alltså är allt icke-noll sant.

Så i detta exempel görs det helt korrekt:
if(!(PINB & (1<<PB7)))
Det kan översättas till: Om innehållet i minnet som PINB pekar på AND'ad med 0x80 ICKE är sant, utför då ...