Hur nära kan man komma åt hårdvaran via C vs C++?

[Al_Bundy]

Hej!

Detta är bara en nyfikenhetsfråga. Jag är C-programmerare och Visual Basic.NET-programmerare men jag har kört C++ ibland. Normalt gillar jag inte C++ om man bortser från klasser som faktiskt underlättar. C++ för mig är allt för stort och onödigt. Man klarar sig hur bra som helst med C.

Jag använder C när jag skriver kod till mikroprocessorer. Varför vet jag inte. Jag frågade bara någon som var kunnig och den sa "Lär dig C. Det räcker". Jag har också hört att C har lättare att komma åt hårdvara än C++. Kan någon förklara för mig hur? Vad är det C++ inte kan som C kan? Varför just C oftast populärare vid hårdvaruprogrammering än C++?

Tackar för svar!
Al

[Zeela]

Helt ovetenskapligt så tycker jag så här: ( )

C++ är ett objektorienterat språk, som har klasser, STL och lite sånt. Det är det som skiljer det från C.
C++ brukar ta upp mer plats både i RAM och i binärfiler än vad C gör, vilket gör det lite olämpligt i en mikroprocessorer där detta är trånga sektorer.

[johano]

C++ kan allt som C kan och lite till..

Anledningen till att C är populärt bland de som skriver kod på låg nivå (nära hårdvaran) är att resurserna
där ofta är begränsade där och då kan C vara lämpligare då den av kompilatorn genererade koden kanske
har något mindre overhead.

Men, använder man C++ på rätt sätt så kan man producera minst lika effektiv kod som i C...

/johan

[sodjan]

Det är ju inget generellt att "A har lättare att komma åt hårdvara än B".
Det beror helt och hållet på hur "A" resp "B" är implementerat. D.v.s
om det finns stöd för (symboler o.s.v) för t.ex hårdvaruregister.

Att en C kompilator har stöd för en viss hardvara beror på att
någon har gjort det tillägget, inte på att det är C i sig.

Sen så är det väl så att det som C++ tillför jämfört med "vanlig C"
kanske inte är till någon större nytta på (mindre) mikrokontrollers.

[Al_Bundy]

Linus Torvalds sa en gång i tiden att C++ var ett hemskt språk. Jag har även i nutid hört samma sak från övriga programmerare.

Även ID Software(de som lade grunden till moderna spel) skapade 3D grafik och spel i rent C. T.ex Quake III kan köras på en Raspberry PI än idag utan problem.

[sodjan]

Tja, gör som du vill. Eller som mr Torvalds tycker,
om du hellre vill det...

[TomasL]

C eller C++ spelar ingen som helst roll, man kommer åt hårdvaran precis lika bra/dåligt oavsett.
Orsaken till att C är populärt är väl att det inte finns så många C++ system för dessa processorer.
uChip släppte en C++ kompilator till PIC32 för något år sedan, till de andra finns inga (vad jag vet).

Huruvida du kan spela quake på rasbpi eller inte hart inget med språket att göra, enbart om det finns en kompilator för hårdvaran du använder, inget annat.
Du kan inte köra quake på en Rasbpi utan att kompilera den för just Rasbpi'n.

[ensamresande]

C++ är hela C plus klasser och andra bibliotek. Du kan ta ren C kod och kompilera med en C++ kompilator och det kommer att fungera.

Jag tror att det finns två anledningen till att C++ är ovanligt i mikroprocessorer. För det första så finns väldigt lite behov av det, man har sällan så komplicerade program att man behöver arbeta objektorienterat (vilket är den största fördelen med C++). För det andra så är koden som genereras av en C++ kompilator så pass mycket större att den tar för mycket resurser.

[TomasL]

Att c++ koden skulle bli större är fel. Det beror i så fall på en inkompetent programmerare.

[MiaM]

Det finns en rätt stor skillnad som kan vara viktig när man pysslar med hårdvarunära saker.

I C är programflödet alltid helt givet. Programmet börjar med första kodraden i funktionen main().

I C++ så körs konstruktorer till diverse klasser innan första raden i main() körs, åtminstone ifall main() använder några klasser.

Det kan leda till problem, på viss hårdvara måste man kanske göra vissa uppstartgrejer i viss ordning.

Jag är osäker men man kanske kan komma runt det genom att ha en main() som är skriven mer eller mindre som vanlig C, och som i sin tur anropar "main2()" som nyttjar C++-saker.

Det finns säkert nån slags specar på i vilken ordning saker görs i C++, men det känns ändå lite lagom osäkert.


Allmänt vad gäller att komma åt hårdvaran så är det väl i övrigt ingen större skillnad. I båda språken kan man tilldela en pekare adressen till hårdvara och med lite kunskap om hur kompilatorn är gjord så kan man pilla på minnesmappad hårdvara direkt. I/O-mappad hårdvara (som på t.ex. x86 och dess föregångare 8080, 8085, Z80 o.s.v.) kräver funktioner i libbar (eller egna assemblersnuttar). Olika kompilatorer är olika lämpliga/olämpliga. Man vill ju ofta vara säker på att det bara görs en access mot I/O-adressen och man vill ju också ofta vara säker på att den sker med önskad bredd (d.v.s. t.ex. 8 bitar). Volatile-deklarering hjälper men C-standarden kräver inte att det faktiskt ska fungera.

Fast det finns ju knappast någon C-kompilatorer för mikrokontroller och andra småprocessorer som inte har stöd för att pilla på hårdvaran direkt.

Det var ju dessutom rätt vanligt även på "vanliga" kompilatorer på den tiden man körde OS där programmen förväntades pilla direkt på hårdvaran, t.ex. på den gamla onda MS-DOS-tiden.

[sodjan]

Provade att köra samma enkla C kod genom både C och C++ kompilering.
Koden från själva C filen blev ungefär lika stor i båda fallen (400-450 bytes)
men vid länkningen av objektfilen körd genom C++ kompilatorn läggs det
till en del C++ kod om ca 20 Kbytes.

C kompilatorn:

Kod: Markera allt

$ cc  lf.c
$ link lf
$ d/sin=22:24

Directory USER:[JANNE]

LF.EXE;13                                     3KB  17-SEP-2014 22:24:35.07
LF.OBJ;16                                     2KB  17-SEP-2014 22:24:29.85

Total of 2 files, 6KB

C++ kompilatorn:

Kod: Markera allt

$ cxx  lf.c
$ cxxlink  lf
$ d/sin=22:25

Directory USER:[JANNE]

LF.EXE;14                                    26KB  17-SEP-2014 22:25:47.21
LF.OBJ;17                                     2KB  17-SEP-2014 22:25:39.86

Total of 2 files, 29KB

Det är några extra C++ moduler som läggs till:

Kod: Markera allt

                                             +------------------------+
                                             ! Object Module Synopsis !
                                             +------------------------+

Module Name        Ident   Bytes File                                 Creation Date      Creator
-----------        -----   ----- -----                                -------------      -------
LF                 V1.0      440 USER:[JANNE]LF.OBJ;12                17-SEP-2014 22:07  Compaq C++ V6.2-016
CXXL$VMS_CXX_EXC   2.012   15944 SYS$COMMON:[SYSLIB]LIBCXXSTD.OLB;1    9-APR-1999 12:22  DEC C V5.7-004
CXXL$MSG           1.0-11   4729 SYS$COMMON:[SYSLIB]LIBCXXSTD.OLB;1    9-APR-1999 12:22  Message A02-12
CXXL$ALPHA_EXCPT   1.1        56 SYS$COMMON:[SYSLIB]LIBCXXSTD.OLB;1    9-APR-1999 12:22  MACRO-64 V1.1-087

I C fallet ingår enbart LF.OBJ i EXE'n.
Som sagt, jag vet inte hur representativa dessa kompilatorer är...

[ensamresande]

Att c++ koden skulle bli större är fel. Det beror i så fall på en inkompetent programmerare.

Jag kanske uttryckte mig lite klumpigt. Ett program skrivet i C kommer så klart inte att bli väldigt annorlunda om det skrivs på liknande sätt i C++, men om man använder klasser, konstruktorer, polymorphism, arv och allt annat som C++ erbjuder så kommer det tveklöst att kräva mer resurser. Och skriver man i C++ så vill i alla fall jag använda allt detta, för det är ändå därför man skriver i C++ och inte C.

[dangraf]

jag har skrivit en del kod i både c och c++ för en stm32 processor. Om den klassas som stor eller liten vet jag inte riktigt..

Jag har kodat i C under flera år och min kod har blivit mer och mer objektorienterad, dvs att man gör en struct med funktionspekare och variabler och att man alltid skickar med denna strukt i sina funktions-anrop.

Anledningen till detta är att mina program har ofta blivit ganska stora och att man skriver samma kod om och om igen med små skillnader. Hittar man buggar är det lätt att man fixar på ett ställe och missar på ett annat. Problemet med denna metod i C är att det lätt blir rörigt med alla pekare och man gör wrappers i defines som kan hitta på hyss om man inte har stenkoll på läget.

Det där med att en massa konstruktorer körs om man initierar i C++ jämfört med C vet jag inte riktigt vad det innebär. Innan man kört sin main-funktion så har väl inga klasser skapats? Däremot initieras en hel del variabler innan man kommer till main vilket är lika för både c och c++. Det är bara att sätta en break-point i c-startup filen så kan man se vad som händer och vad som initieras. jag har inte gjort detta för c++ så jag vet inte om någon kod från klasser körs innan man kommer till main.
Sedan har jag för mig att det sker en extra kopiering när man kör c++ och returnerar ett värde. Men även här skulle man lätt kunna kontrollera om detta gäller för en specifik kompilator genom att stega koden och se hur många cykler en retur-kopiering tar beroende om man kompilerar för c/c++.

Det var lite problem med interrupt i C++, har för mig att man inte kan kalla på ett objekt från ett interrupt. Jag mins inte på rak arm exakt vad problemet var.

Det går även att kompilera vissa filer (t.ex *.c) med en c kompilator och andra filer (*.cpp) med c++ kompilator därefter kan man länka ihop objektfilerna till en körbar fil för processorn om man skulle vilja detta. Precis på samma sätt som att man kan kompilera vissa filer i asm och länka ihop med C kod.

[dangraf]

Det där med att C++ kräver mer resureser vet jag inte heller riktigt. C++ gör ju samma sak som jag gjorde manuellt i C genom att man skapar en strukt med funktionspekare. För att initiera strukten så körs såklart en init funktion eller en konstruktor som talar om ifall man skall plocka ihop sitt eget paket av funktionspekare (arv etc). pekaren till denna strukt kopieras till alla funktioner i klassen så att man håller koll på variablerna för just det objektet. Så, ja det skapas en extra variabel i form av this pekaren. Annars vet jag inte riktigt vad som skulle ta en massa extra resurser

[TomasL]

ensamresande, Det är också det jag menar, man kan inte skriva ett C++ program på samma sätt för en uC som för en x86, då blir koden större, men om man använder de fördelar som C++ ger gentemot vanlig C så blir skillnaden inte så stor.
Man måste naturligtvis tänka sig för.
Sedan kanske man inte använder C++ till en lite PIC16/18 eller liknande, då programminnet ändå är så litet så man inte kan göra några komplicerade saker ändå, däremot om man jobbar med 32-bitars processorer såsom PIC32 där vissa har 2M flash och 0,5M RAM, då blir det lite annorlunda, eftersom man helt plötsligt kan göra betydligt mer avancerade saker.