Svenska ElektronikForumet

Är detta en effektiv, och fungerande, multiplikation i C Assembler?
(stoppa gärna in semikolon där sådan skall vara, liksom andra behövliga korrektioner)

Givet: p, x och y får plats i sina givna former.

p = 0
while x ≠ 0
{
if x.0 = 1
{
p = p + y
}
[arithmetic right rotate] x
[arithmetic left rotate] y
}

Det ser ut att vara det vanliga sättet man gör i assembler.

Men
P = X * Y;
fungerar bra det med.

> Är detta en effektiv...

Sannolikt inte.

> och fungerande...

Kanske (har inte kollat).

Men "*" är både effektiv och fungerar garanterat.

Tack Icecap, det var tanken.

Det var lättare beskriva i ~C.

Nu är bara frågan hur man utför division på liknade vis...

Sättet ovan drog jag ut ur Grundläggande datorteknik [Olof Roos], sid 29.

sodjan - det är p = x * y [ett, av flera, sätt]

Jag undrar vad lite varför du Söker andra sätt i C för att multiplicera och dividera än dom enklaste sätten.
* och /. blir det snabbare och eller bättre maskinkod om man komplicerar till det enligt ditt exempel.

Eller är det bara för att det går? Jag har inte den bok du refererar till [Olof Roos] så jag kan inte läsa in bakgrunden till det hela, där finns säkert någon smart förklaring. Ber om ursäkt för min okunnighet. För mig har det alltid funkat med "*" och "/".

Självklart kan man göra så - men det ändrar inte att det INTE är en effektiv metod, utförd i C.

Men ska man bara utföra enstaka beräkningar av den typ kan man låta bli att ta in ett matte-bibliotek i källkoden så i vissa - mycket specifika - fall kan man spara lite minne på bekostnad av hastigheten.

Programmerar man C använder man * och /
Eller om det är som jag gissar, att du vill ha fram mest effektiva sättet att göra det i assembler (du verkar mest skriva assembler baserat på dina tidigare trådar) så kan du ju skriva en kort C-funktion som använder *-operatorn, kompilera med max optimering på, och sen köra binärfilen genom någon disassembler.
Eller så skaffar man en riktig processor, som har hårdvarumultiplikator

Anledningen till varför jag gör mig sådant besvär med optimering, och därmed endast Assembler, är den tidsnöd applikationerna lider av. Speciellt då ADC-cykeln tar så förbaskat lång tid...
Att använda C ger inte en väg kort nog. Basic gör, men inte C.
C kan, möjligen, användas till tidiga utkast för kod - när den förts vidare till HEX/ASM.
Japp, jag gör ingen egentlig skillnad mellan de två, de är två sätt skriva samma sak.

Jag skulle vilja ha tag på en Basic compilator. Inte VB då alltså, utan DOS/Q/etc-Basic.

Jag programmerar alltså inte i C.
Jag använde en C-liknande syntax för att göra en förenklad, men fortfarande originalnära, funktion att ställa frågan med.

Erik: Om du använder en seriös kompilator finns det en viss liten chans att du genom att handassemblera kan generera bättre kod. Men chansen är löjligt liten. Vad amvänder du för kompilator? Till PIC skulle jag säga att endast HiTech från Queensland och Microchips avknoppningar är något att ha.

Att hävda att BASIC skulle vara effektivare än C tyder på en viss förvirring. Men det är inte (än så länge) förbjudet.

Edit: Felstavning.

Som sagt var - kraven applikationerna ställer.

Och varför strula till det med högre nivå på språk än nödvändigt?
Så länge det gäller logik är enkelt... enklare. Dessutom även bättre.

När det kommer till aritmetik är den lägre nivån fortfarande bättre, om än, till synes, krångligare.
Till synes, som synes av den kod jag tog fram ovan. Dvs den typ av kod som utför multiplikationen.
Jag skriver vad som händer, med C skriver du vad du vill ska hända. Och hoppas att C gör som du tror.

Eventuell förvirring får du stå för själv.

Frågan om varför, eller inte, C är... som den är.

Personligen används redskap bäst lämpade.

Jag skulle (igen) vilja påstå att det bäst lämpade redskapet, om prestanda är ett krav, är en processor med dedikerade instruktioner för multiplikation.
En 'mul x,y'-instruktion är garanterat snabbare än vilken mjukvarumultiplikator som helst. Och modernare MCU:er har ofta snabbare ADC:er också.

Erik M: Jag ber om ursäkt för att jag har svarat i din tråd. Det har uppenbarligen inte gjort något som helst intryck på dig. För min del spelar det ingen som helst roll men för din del tror jag att det kommer att innebära sämre förmåga att lösa uppgifter som har med "embedded" att göra. Återigen, jag ber om ursäkt. Lycka till!

Personligen används redskap bäst lämpade.

Uppenbarligen gör du inte det, eftersom du startade denna tråden.

> kompilera med max optimering på, och sen köra binärfilen genom någon disassembler.

Finns det *någon* vettig C-kompilator som inte kan ge en assembler list-fil?
I alla fall som en option...

Hur som helst, om man nu är ute efter "rå" prestanda så är det viktigaste att
analysera *varför* man vill göra en multiplikation överhuvudtaget. Väldigt ofta
kan en analys av fallet ge att man genom att skala parametrarna kan komma
runt det genom några enkla shift eller liknande.

Om den ena parametern i multiplikationen skulle råka vara en konstant
så går det ofta att optimera rutinen för just det värdet. Det finns ett verktyg
som ger minsta PIC kod för att göra en multiplikation med en konstant:
http://www.piclist.com/techref/piclist/ ... divmul.htm

Ett exempel på en 24 x 24 bit multiplikation:
http://www.piclist.com/techref/microchi ... 4b-fm1.htm

Finns massor av teori kring mult/div rutiner:
http://www.piclist.com/techref/method/math/muldiv.htm