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

[Nerre]

Lisp nedåtgående? Inte så länge Emacs finns:)

[TomasL]

ärligt talat, de enda gångerna jag stött på LISP är med AutoCad, på DOS-tiden

[Jan Almqvist]

B är utdött. Pascal och COBOL är väll också utdöende språk.

Jag skrev "stort programmeringsspråk", B var väl aldrig så stort?

Pascal används som sagt var i Delphi, jag tror inte Cobol är helt utdött heller. Det finns i alla fall en OpenCobol som fick sin senaste uppdatering 28 augusti i år.

Pascal är väl konstruerat för utbildning, inte för "riktig" programmering?

[xxargs]

Ingen av dessa (inte java heller) är direkt kända för lågnivåpill...

Den första och enda gången jag försökt med Pascal så föll det på att jag ville accessa direkt till en UART eller om det var en register kopplad till en V24-port (det var på ABC-80 tiden...), kort sagt den var oanvändbar till något annat än vad de inbyggda biblioteken supportade och på de tiden hade jag ingen aning hur man skrev hårdvarunära egna bibliotek i pascal.

tom. Basic peek och poke var mer användbar...

Frågan är snarare vilka andra språk än C som kan prata med register och HW-io eller om man vill, att kunna tillverka en drivrutin till en specifik hårdvara i stort sett helt och hållet i språket

Att C används till vad den nu används i hårdvarunära miljöer har nog sina orsaker och knackar man OS-kod så är det just att hantera HW som gäller till stor del.

[sodjan]

> Att C används till vad den nu används i hårdvarunära miljöer har nog sina orsaker...

Japp! Och det är ju å andra sidan inte speciellt förvånande.
C är/var från början ett implementationsverktyg för OS och maskinnära programmering.
Klar som tusan att C då har fler funktioner för just *det*!

Men, sen är det ju inget tekniskt som hindrar att man fixar liknande
tillägg till i princip vilket språk som helst, om behovet/markanden finns.
MikroPascal från Mikroelektronika för PIC/AVR t.ex, bara för att just Pascal nämndes.

> Frågan är snarare vilka andra språk än C som kan prata med register och HW-io...

Vilket annat språk som helst, om man bygger in stödet för det. Det finns inget med själva
språket C som gör det speciellt, det har mer med dess historiska bakgrund att göra.

[Krille Krokodil]

Finns produkter för de som vill programmera uC men inte överge sitt kära gamla Basic eller Pascal:

http://www.mikroe.com/

C fortsätter väl att vara störst för att alla tillverkare fortsätter göra/stödja bibliotek för
de hårdvarunära funktionerna i det när de släpper en ny krets, kunde lika gärna varit
X, Y eller Z men nu blev det C som en gång i den digitala forntiden fick ett försprång
som än idag består.

[kodar-holger]

Frågan är snarare vilka andra språk än C som kan prata med register och HW-io eller om man vill, att kunna tillverka en drivrutin till en specifik hårdvara i stort sett helt och hållet i språket

Ada

Kod: Markera allt

declare
  type Byte is range 0..255;
  for Byte'Size use 8;
  for Byte'Alignment use 8;
  A:Byte;
  for A'Address use 16#000000F7#;
begin
  null;
end;

Inbyggt i språket. Och portabelt mellan kompilatorer. Kallas representation clause. Mycket användbart. Även om det är konstruerat för direkt hårdvaruaccess så är det nog mest använt för interfacing mellan språk. Man kan naturligtvis lätt repspeca records och uppräkade typer också.

Har du det i C? Portabelt mellan kompilatorer?

Antalet Ada-Programmerare i världen ökar dessutom, även om marknadsandelen minskar. Så utdöende? Nja, inte direkt förestående i alla fall.

[Nerre]

ärligt talat, de enda gångerna jag stött på LISP är med AutoCad, på DOS-tiden

Och bara för att du aldrig använt Emacs så finns den inte eller?

[Nerre]

Ingen av dessa (inte java heller) är direkt kända för lågnivåpill...

Nej men det handlade det ju inte om här, det var ett sidospår om vilka språk som eventuellt är utdöda idag.

[jesse]

Kan inte du visa en exempelkod av C som är objektorienterad? Ta något enkelt t.ex bil, färg, modell osv?

Jag vet inte om allt är helt korrekt enligt C, men ungefär kan man göra så här: (inte helt komplett)

Kod: Markera allt

/******************** datastrukturer - bilar - ägare ***********************/

#define STRLEN 20 // max antal tecken i en textsträng inkl avslut (\0x00)

// *** enumerationslistor *** //
typedef enum {ej_def, vit, gul, gron, rod, bla, svart, annan} fargTyp;
typedef enum {ej_def, volvo, saab, renault, vw, annan} modellTyp;

// typdeklaration person - innehåller data om person: namn, adress, telefonnummer, antal fordon, länk till fordonslista
typedef struct {
	char namn[STRLEN];		// namn
	char adress[STRLEN];		// adress
	char namn[STRLEN];		// telefonnummer inkl riktnummer
        int antal_fordon;                // antal fordon i registret kopplad till denna ägare
        bil *lista                            // länk till bil-registret
} person;

// typdeklaration bil - innehåller data om ägare, färg, modell mm...

typedef struct  {
	modellTyp modell;              // bilmodell
        fargTyp farg;                      // färg
        person *agare                    // länk till ägare
} bil;

/*************** variabler ******************/
person folkbokforing[1000]; // lista på alla medborgare, max 1000 personer
bil bilregistret[1000];  // lista på alla bilar

/******************* main ***********************/
int main(void)
{
	person[1].namn = "Al Bundy";
	person[1].antal_fordon = 1;
	bil[1].modell = volvo;
	bil[1].farg = gron;
	bil1.agare = &person[1];

	print_person(1); // funktion - skriv ut person nr 1
	print_bil(1);// funktion - skriv ut bil nr 1
}

/************* funktioner (metoder) som hanterar objekt av typen "person" ********************/
void print_person(int nr)
{
	//... skriv kod här ....
}

/************* funktioner (metoder) som hanterar objekt av typen "bil" ********************/
void print_bil(int nr)
{
	//... skriv kod här ....
}

Om det handlar om riktigt stora och komplicerade objekt är det en bra idé att skapa en helt egen h-fil för deklarationerna och en c-fil för objektets metoder (funktioner). Då har man hanteringen av en viss typ av objekt på samma ställe och rör inte ihop det.

[ronnylov]

En möjlighet är att man utvecklar de hårdvarunära bitarna med C (eller något annat lämpligt hårdvarunära språk) och resten med ett högnivåspråk på en högre nivå än C.

På samma sätt som att ett operativsystem kan vara skrivet i C och programmen som användaren kör är gjorda med något högnivåspråk så kan man ju göra på samma sätt i sina program att blanda olika programmeringsspråk beroende på vad som är lämpligt i de olika delarna. Sedan kan man förstås ha begränsningar på vilka programmeringsspråk som stödjer plattformen. Men säg att man ska göra ett grafiskt användarinterface, då kanske man kan göra detta i Python och sedan när knappar och menyer aktiveras anropar man rutiner skrivna i C om det behövs. Fast dagens datorer är så snabba så det är väl sällan det behövs av prestandaskäl men möjligheten finns om det behövs.

Inbyggda system programmerar man i och för sig ofta direkt mot en MCU med C eller kanske C++. Men idag är det heller inte ovanligt att de kör inbyggda operativsystem såsom Linux och då har man större frihet när det gäller programmeringen eftersom själva operativsystemet kan sköta det mesta i bakgrunden när det gäller den hårdvarunära biten.

[Nerre]

Ja, precis, ett programmeringsspråk är ju bara ett sätt att göra saker enklare. Beroende på vad man vill göra passar olika programspråk olika bra, men i slutänden är det ju maskinkod som ekekveras av processorn. (Dock inte säkert att själva programmet blir maskinkod, det kan ju bli nåt mellansteg eller vara interprerat:)

Det är väl också därför väldigt få språk dör ut, de flesta språk har sin egen nisch där de passar bra.

[johano]

Jag ser fler och fler skriver "man kan visst programmera objektorienterat med C!!!". Men varför sägs det allmänt att man inte kan göra det?

Jag är helt övertygad att man kan programmera objektorienterat via C, utan dessa "C++ klasser". Men jag har aldrig sett något exempel

Här är ett exempel på hur man skulle kunna tänka lite "objektorienterad" i C:

Kod: Markera allt

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

typedef void (*work)(void*);

typedef struct _person {

    char name[20];
    int age;
    struct _person* owner;
    work dowork;
} Person;

typedef struct
{
    Person person;
    char title[20];
    
} Manager;


typedef struct
{
    Person person;
    char title[20];
    char workdescription[50];
    
} Employee;



void manager_work(Manager*manager)
{
    printf("Manager %s is now busy doing whatever a %s is doing\n", manager->person.name, manager->title);
}

void employee_work(Employee*employee)
{
    printf("Employee %s is now busy doing whatever a %s is doing: %s\n", employee->person.name, employee->title, employee->workdescription);
}


Employee* createEmployee(Person*owner, char*name, char*title, char*workdescription, int age)
{
    Employee *newEmployee = (Employee*)malloc(sizeof(Employee));
    
    newEmployee->person.owner = owner;
    newEmployee->person.dowork = (work)employee_work;

    strcpy(newEmployee->person.name, name);
    newEmployee->person.age = age;
    strcpy(newEmployee->title, title);
    strcpy(newEmployee->workdescription, workdescription);
    
    return newEmployee;
}

Manager* createManager(Person*owner, char*name, char*title, int age)
{
    Manager *newManager = (Manager*)malloc(sizeof(Manager));
    newManager->person.owner=owner;
    newManager->person.dowork = (work)manager_work;
    
    strcpy(newManager->person.name, name);
    newManager->person.age = age;
    strcpy(newManager->title, title);
    
    return newManager;
}



int main(int argc, const char * argv[])
{
    Person *theOwnr = (Person*)createManager(NULL, "Jack Owner", "Founder", 56);
    Person *theBoss = (Person*)createManager(theOwnr, "John Boss", "Supermanager", 22);
    Person *theDude = (Person*)createEmployee(theBoss, "Jim Worker", "Code monkey", "Produce code as fast as hell", 43);
    
    theOwnr->dowork(theOwnr);
    theBoss->dowork(theBoss);
    theDude->dowork(theDude);

    free(theOwnr);
    free(theBoss);
    free(theDude);

    return 0;
}

Edit: ett enklare "frukt"-exempel:

Kod: Markera allt

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

typedef void (*describe)(void*);

typedef struct {

    describe describe;
    
} Fruit;

typedef struct
{
    Fruit fruit;
    
} Apple;


typedef struct
{
    Fruit fruit;
    
} Banana;

typedef struct
{
    Fruit fruit;
    
} Orange;



void describe_apple(Apple*apple)
{
    printf("An apple is round, either green or red. It does not have to be pealed\n");
}

void describe_banana(Banana*banane)
{
    printf("A banana is yellow, long and slightly curved and needs to be pealed before eating\n");
}

void describe_orange(Orange*orange)
{
    printf("An orange is round and orange, it needs to be pealed before eating\n");
}


Apple* createApple()
{
    Apple *apple = (Apple*)malloc(sizeof(Apple));
    apple->fruit.describe = (describe)describe_apple;
    
    return apple;
}

Banana* createBanana()
{
    Banana *banana = (Banana*)malloc(sizeof(Banana));
    banana->fruit.describe = (describe)describe_banana;
    
    return banana;
}

Orange* createOrange()
{
    Orange *orange = (Orange*)malloc(sizeof(Orange));
    orange->fruit.describe = (describe)describe_orange;
    
    return orange;
}


int main(int argc, const char * argv[])
{
    Fruit* fruit1 = (Fruit*)createApple();
    Fruit* fruit2 = (Fruit*)createBanana();
    Fruit* fruit3 = (Fruit*)createOrange();
    
    fruit1->describe(fruit1);
    fruit2->describe(fruit2);
    fruit3->describe(fruit3);

    free(fruit1);
    free(fruit2);
    free(fruit3);
    

    return 0;
}

[sodjan]

Våra applikationer "på jobbet" har affärslogiken i Cobol och sedan finns det
olika rutiner i t.ex C, Fortran och Macro (ASM) som anropas. Eftersom miljön
har ett "Common Language Environment" så behöver man sällan bry sig
om vad det är för språk som de olika modulerna är skrivna i, det är en
gemensam "Calling Standard", d.v.s hur parametrar hanteras o.s.v.

Jag kollade på något exempel för ett tag sedan och det var över
10 olika källor till objektfilerna om man även räknar med olika
versioner av kompilatorerna. Objekt filer som inte har kompilerats
om de senaste 15-20 åren medan kompilatorn har uppgraderats
flera gånger o.s.v. På en väldesignan plattform är alltså detta
inget problem.

EDIT:
Dessa kompilatorer används för ett av våra program
med exempel på tidpunkt för senaste komplering:

Kod: Markera allt

 18-AUG-1994 12:48  AMAC V2.0-22
 10-APR-1999 14:14  AMAC V3.1-23A1
 10-APR-1999 14:28  BLISS-32E V1.3-023
 12-JUL-2001 17:10  Compaq COBOL V2.7-1209
 13-DEC-2012 07:06  Compaq COBOL V2.8-1286
 10-APR-1999 10:36  DEC C V5.0-003
 14-OCT-2003 14:17  DEC C V5.6-003
 19-NOV-1998 07:43  DEC COBOL V2.0-271
  1-FEB-1995 08:18  DEC Fortran V6.2-508
 27-SEP-1994 13:57  Linker A11-14
 20-JAN-2000 10:05  Linker A11-20
 22-APR-2003 09:10  Linker A11-50
 10-APR-1999 14:14  MACRO-64 X1.1-016
 10-APR-1999 13:54  Message A02-12
 15-SEP-2006 15:39  Oracle Rdb SQL V7.0-2
 11-FEB-2007 10:06  Oracle Rdb SQL V7.2-010

Bl.a 3 Cobol versioner och 2 C versioner (aktuell installerad C är V7.3).

AMAC är 32-bit assembler, MACRO-64 är 64-bit assembler (vilka på
Alpha är kompilatorer, de kompilerar VAX assembler till Alpha maskinkod).
http://en.wikipedia.org/wiki/VAX_Macro

BLISS är en lite udda fågel: http://en.wikipedia.org/wiki/BLISS
"BLISS is a system programming language developed at Carnegie Mellon University by
W. A. Wulf, D. B. Russell, and A. N. Habermann around 1970. It was perhaps the best
known systems programming language right up until C made its debut a few years later."

[xxargs]

Finns produkter för de som vill programmera uC men inte överge sitt kära gamla Basic eller Pascal:

http://www.mikroe.com/

C fortsätter väl att vara störst för att alla tillverkare fortsätter göra/stödja bibliotek för
de hårdvarunära funktionerna i det när de släpper en ny krets, kunde lika gärna varit
X, Y eller Z men nu blev det C som en gång i den digitala forntiden fick ett försprång
som än idag består.

Om man snävar till kraven att man skall kunna skriva lågnivådrivrutiner själv i kompilatorn _utan_ stöd av andra produkter än det som kommer med en standard kompilatormiljö (ok assembler är tillåten för tex inline-assembler i språket eller för dom första byten startuppkod, om den finns i kompilatormiljön från början), hur många då kan hacka lågnivå med direkt HW-adressering etc. på något så när strukturerat sätt (dvs. lite mer kontrollerat än peek och poke ala basic) ??

dvs. en standard pascalkompilator, en standard basic, standard java, standard C#, standard fortran, lisp, basic etc. etc. - för man kan hamna i situation att mer än så har man inte tillgång till och ingen tillverkare av HW är villig att hjälpa till med drivrutiner för just sin kompilatormiljö eller som i linuxvärlden under många år och än idag, har reverse engineerat massor av HW - och inte minst, att man själv utvecklar egen mjukvara och man är sin egen 'tillverkare'...

Många högnivåspråk är beroende på att det redan finns en plattform som servar kompilatorn och resulterande program när den skall köras och få av dessa är mogna att kunna skriva BIOS och systemanrop i om nöden så kräver...

som redan sagt så är 'C' ett tillämpningsspråk för att skriva OS i och där handlar det till stor del om att just hantera hårdvara.