Svenska ElektronikForumet

sodjan skrev:> ...kör man gcc så kan man i alla fall kolla hur koden för kompilatorn ser ut.

"Kan" är inte detsamma som att det är vettigt, rimligt eller ens önskvärt.

Chansen är ju helt klart större att man kan "reparera" koden det tvistar jag absolut inte om.

MEN frågan som jag ställer mig är det rimligt att jag som önskar koda pic/avr/Renesas först ska "rätta" kompilatorn sen få igång vad det nu är jag vill få igång. Känns lite på tunn is där.

Visst möjligen om man på något sätt MÅSTE rätta en obsolete processor där programmet inte fungerar på ny hårdvara etc. men då är det ändå ett specialfall.

vespaman:Dreambox är inte helt öppen nej, jag använder en annan firmware som finns som OS, det är ett insticksprogram/plugin till detta som krånglar. Nu har jag gett upp men ack så frustrerande det var(/är). Dreambox samt dess customfirmware (gäller även original) känns som ett hopplock där det inte finns support eller någon "samlad" kunskap utan man får fråga på forum eller googla sig pissless och sen testa en massa "lösningar" som kanske är relaterade eller tom avlägsna till problemet.

sodjan skrev:> ...kör man gcc så kan man i alla fall kolla hur koden för kompilatorn ser ut.

"Kan" är inte detsamma som att det är vettigt, rimligt eller ens önskvärt.

Jag har så klart inte sett hur gcc koden ser ut "under the hood" men
jag misstänker att man bör vara rellativt beläst inom kompilatorteknik
för att hänga med i vad de gör. För de allra flesta är det där ett
argument helt utan värde, ändå är det ett av favoritargumenten
från open source förespåkarna. Märkligt...

Det jag sett och det jag hört om gcc koden "under the hood" är att den är minst
sagt "snårig".
GCC är en utmärkt kompilator, men det finns en annan open source kompilator
med snyggare design/kod, LLVM.

Jag har spenderat kvällar på min fritid den senaste månaden att skriva ett backend
för OpenRISC till LLVM, och den börjar nu så smått börja kunna kompilera vettiga
program och jag är inte särskilt beläst inom kompilatorteknik
(men det är klart jag lärt mig en del under den senaste månaden).

Poängen är att det inte alls är omöjligt att utan någon större
erfarenhet gå in i en kompilator och fixa saker, så länge den är vettigt uppbyggd.
(Backenden i LLVM är väldigt separerade från t.ex. optimiseringspassen,
så det är mycket som man inte behöver "bry sig om" om det nu t.ex. skulle
vara en arkitekturspecifik bugg det är frågan om).
Sen om det är rimligt att man gör det är ju en annan sak.

Edit: här finns OpenRISC LLVM backendet, om någon skulle vara intresserad: https://github.com/skristiansson/llvm-or1k

> Sen om det är rimligt att man gör det är ju en annan sak.

Ja, det är ju uppenbart att det inte är det. Ändå är det, som jag
sa, ett av favoritargumentet från OSS förespråkarna, "det är bara
att fixa det själv"...

Om du utvecklar professionellt och har produkter som dina kunder förväntar
sig support på under längre tid, så är det inte ovanligt att man tecknar avtal
med sina leverantörer av verktyg kring framtida support över en lite längre tid.

Men å andra sidan så verkar det idag som att de flesta har svårt att se förbi
närmaste kvartalsrapport och ennu svårare vi börjar räkna flera år framåt...

Jag tycker det är en trevlig utveckling att t.ex Gcc och Eclipse blir allt vanligare. Jag har alltid retat mig på att alla dessa utecklingsmiljöer har sina egna användargränssnitt. För C-programmering brukar det mesta vara väl utvecklat men det är ändå trist att lära sig en ny miljö från grunden. När det gäller VHDL har jag stött på flera konstiga gränssnitt och där hade Eclipse varit ännu trevligare.

Nu börjar den här tråden bli riktigt offtopic, men:
Det finns väl inget som hindrar att du använder Eclipse till VHDL utvecklandet?
De flesta (om inte alla) syntes och simulatorverktygen går att hantera via kommandoprompten,
vilket medför att du utan problem kan driva dem mha makefiler, vilka du i sin tur kan köra från eclipse.
Var väldigt länge sedan jag öppnade några av de otympliga "IDEerna" som tillhandahålls,
jag använder iofs hellre emacs som editor för VHDL/verilog, men principen är ju den samma.

Diskussionen tog stopp helt plötsligt så jag får väl slänga in lite bensin på brasan...

Helt klart så ser man ju att flera halvledartillverkare går över till ARM-arkitekturen vilket
kan vara förståeligt. Man behöver inte förlita sig på att någon andrapart ska ta fram
utvecklingsmiljö. Man får en beprövad plattform till sitt eget kisel/periferi, etc... Pris på
chipet verkar blir väldigt lågt. Det känns som att vi som är HW-konstruktörer är vinnare
här.

Visst är det en skön känsla att kunna microkoden (assemblern) i en CPU och kunna
peta bort en onödig instruktion och tjäna en us... men sen var det ju att man ska
få fram nyttofunktionen också. Bankswitchningar... out of memory... stack overflow...
Allt sånt skit som man fått harva med pga en begränsad arkitektur. Halleluja, hugg
nästa ARM-chip och fortsätt. Skit i assembler, C-kompilatorn gör assembler. Alla register
måste man dock hålla koll på men så är det.

Här är en länk till Philips (ok, det heter NXP nu) DIL-chip. 32 k flash å 4 k RAM. Förvänta icke för mycket.
http://www.nxp.com/products/microcontro ... kreference

Och en 2x2 mm stor 16 pin (bga) av liknande typ:
http://www.nxp.com/packages/OL-LPC1102UK.html
Jag fick ett sampel av en sån men den försvann i en nysattack!
Själv föredrar jag nog TI:s pryttlar...

Sen kan jag... om jag spottar på fingret och håller upp det i luften... känna en viss
frustration från PICibanerna (vad heter det? Mac har ju sina macibaner?) Nja...
PIC har ju också en 32-bitare. Den kanske är bättre? Vad vet jag.

Nä, nu ska jag gå å tälja på en träbit. Då vet man i alla fall vad man håller på med!

> ...kör man gcc så kan man i alla fall kolla hur koden för kompilatorn ser ut.

Vet inte vem som skrev.
Men i alla fall, varför i helsike vill man veta det, finns ingen som helst motivering eller anledning, utvecklingsverktyget skall fungera, annars ringer man support.

Nu har inte jag skrivit om någon kompilator men tänkte bara höra om inte du svurit långa ramsor över icke fungerande support? Jag har några fall där jag blivit rätt sur t.ex när jag vänt mig till b-knudsen för att modulu kommandot inte fungerade och fick enbart svar att det går att komma runt med en "&" operator. Eller när man haft problem med microchips C18 kompilator för att den vill att man ska casta en char till en char för att jämföra 2st lika variabler eller jämföra med defines. Eller när man använt sig av IARs kompilator och via pragma specifikt placerat en variabel på en given adress med ett givet värde som får ett nytt värde vid kompileringen.

Vid dessa tillfällen skulle det nog gå snabbare att se vad kompilatorn faktiskt gör än att vänta på ett supportsvar i 2v för att därefter inse att de knappt förstått frågan fastän de fått ett referens-projekt skickat till sig

Förstår inte varför man ska behöva vända sig till support eller behöva glo på vad kompilatorn gör bara för
att tillverkaren av utvecklings varan släppt en nästan färdig produkt där man ska behöva spendera tid
på varför den inte funkar till 99%.(ingenting funkar till100%)

Varför vara beroende av en support med noll utslag på EEG:et.. Har man support och tillgång till källkod kan man alltid lösa problemet själv. Visst det är svårt, men inte längre omöjligt.

Finns en poäng i det dangraf säger..

För hobbyister kan det nog vara så, men i yrkeslivet är det inte så.
Jobbar man som programmerare, så jobbar man med företagets projekt, att börja felsöka verktygen finns inte ens på kartan.
Så nej, det är ingen fördel med sk öppna verktyg som gcc.

Intressant att diskussionen egentligen inte rör sig om bussbredden men om verktyget, det går ju helt i stil med min inställning:
Numera är det viktiga inte processorn men verktygen för att skapa program åt dom. Därmed är det även viktigt att se till att man använder ett programmeringsspråk med en standard som kan portas till andra processorer liksom att man måste ha en programmeringsstil som gör att man inte fastnar i little/big edian-problematik och liknande.

Sedan får processorn vara en sävlig modell med bred buss eller en ettrig fan med smal buss, bara den klarar jobbet i tid.

När dessa saker är uppfyllda ska programmen man gör kunde köra på snart sagt alla processorer, dock måste man ha olika hårdvara-interface till programmen.

Och det är faktisk fullt möjligt! Själv använder jag C och har använd exakt samma rutiner helt oförändrade på PIC, Fujitsus FFMC-16LX, Renesas M16C och till program till PC. Jag använder helt enkelt samma C-fil som inkluderas i de olika projekt och jag har ett antal olika för olika funktioner.

Sedan finns det saker som skiljer en del mellan de olika hårdvaror, t.ex. ger FFMC-16LX en interrupt för varje AD-omvandling om man sätter den i löpande omvandling av x kanaler medan M16C omvandlar alla kanalerna och sedan ger en interrupt men det är till att lösa utan besvär i hårdvara-anpassningen.

> För hobbyister kan det nog vara så, men i yrkeslivet är det inte så.
Du menar: men i mitt yrkesliv är det inte så, eller hur?

> Jobbar man som programmerare, så jobbar man med företagets projekt, att börja felsöka verktygen finns inte ens på kartan.
Att det just är en bugg i kompilatorn som orsakar ditt problem är inte alltid så uppenbart,
det är möjligt att du redan är lösningen på spåret när du ringer supporten.

> Så nej, det är ingen fördel med sk öppna verktyg som gcc.
Igen, ingen fördel i ditt tycke.
Helt uppenbart finns det kommersiella aktörer som tycker det är väldigt intressant
med öppna verktyg som gcc eller llvm.

TomasL skrev:För hobbyister kan det nog vara så, men i yrkeslivet är det inte så.
Jobbar man som programmerare, så jobbar man med företagets projekt, att börja felsöka verktygen finns inte ens på kartan.
Så nej, det är ingen fördel med sk öppna verktyg som gcc.

Jag kan bara säga att du har fel med avseende på det generaliserande du gör. Jag är utvecklingschef och på de företag jag jobbat/jobbar har öppna verktygskedjor varit en enorm fördel gentemot många (inte alla) stängda. Och, som jag tror jag skrev i något tidigare inlägg; jag kommer aldrig att gå tillbaka.
Och ja:- jag har haft denna erfarenheten (och positionen) i företag med ~463000 anställda ner till ett med 12 anställda.
Sedan är det upp till var person att ställa sig frågan om man vill/behöver köpa support till GCC (tex), men den frågan kan man isf ta från fall till fall. Många gånger behöver man ju bara slänga ut en fråga på lämpligt forum för att man ska komma rätt.

Observera att jag aldrig har stött på en bug i GCC, men väl i editorer/debuggers osv. Jag har f.n. supportavtal på en GCC kedja av tre som vi kör.

Naturligtvis generaliserar jag.
Vad som är bäst är naturligtvis högs generellt, dock finns det naturligtvis ingen generell fördel med öppen programvara.

Dessutom kan man naturligtvis ifrågasätta, skall företagetsutvecklare jobba med produktutveckling eller fixa till verktygen.
Personligen anser jag att utvecklarna skall jobba med utveckling av företagets produkter.