Wo findet man Programmierer?

Vinzent 'Gadget' Hoefler schrieb:

*Du* sollst nicht, das ist die Aufgabe desjenigen, der die Programmierumgebung zusammenbaut.

Und darüber, wieviel Zeit man in die Programmierumgebung stecken darf, reden wir wohl lieber nicht. ;-) Die für C läuft für Atmel AVR schon seit Jahren, die für Ada steckt immer noch in den Kinderschuhen. Das ist dann die Kehrseite der Medaille.

Wieso? Steht doch ausdrücklich dort, dass es implementation-defined ist. Warum willst du da unbedingt ein undefined reininterpretieren? Wenn natürlich deine Adresse nicht den aligment requirements des Prozessors entspricht, knallt es, aber das ist eine Prozessorfrage. Und *wohin* der Zeiger dann zeigt, das musst du natürlich schon selbst wissen, aber das ist bei Ada nicht anders.

Ich fand diese Definition jedenfalls deutlich strikter, als ich vom C-Standard erwartet hätte. Es wird dem Compiler eben nicht gestattet, heute dies und morgen jenes aus einem derartigen Typecast zu compilieren.

Und bei Ada? Bist du wieder bei demjenigen, der das in die Programmierumgebung hineinzimmern musste und damit u. U. heute noch immer nicht fertig geworden ist...

Versteh mich nicht falsch, ich habe nichts gegen Ada, aber es nun als den Stein der Weisen hinstellen zu wollen, bringt's auch nicht. Viele der Dinge, die du da aufgezählt hast, sind ohnehin eher marginal.

--
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
Reply to
Joerg Wunsch
Loading thread data ...

Hint: Es heisst Einleitungs_zeile_.

Falsch, da komplett dysfunktional. Ich nehme an, Du meintest so etwas:

|typedef struct { /* Annahme: Reihenfolge sei low-order-first */ | unsigned int ras_cas_dly : 2; | unsigned int ras_pchg_dly : 2; | /* das muesste eigentlich ein eigenstaendiger enum */ | /* sein, aber ich bin faul, ignorieren wir das fuer */ | /* heute also mal */ | unsigned int cas_lat : 1; | unsigned int dummy : 3; |} sdram_timing_control_t; | [...] | static volatile sdram_timing_control_t foo = | { ras_cas_dly : 3, | ras_pchg_dly : 0, | cas_lat : 3, | dummy : 0, | };

Wirft einen Binaerwert von (erwartungsgemaess) 000.1.00.11 in die Struktur. Richtig waere allerdings 000.1.00.01. Warum das so ist (und der Rest eigentlich auch nur zufaellig stimmt), ueberlegst Du Dir bitte selbst. (Dass der Compiler nicht einmal warnt, dass mindestens einer der zugewiesenen Werte gar nicht in das Bit-Feld passen, ist da nur noch eine der Nebensaechlichkeiten, an die man sich im Umgang mit C gewoehnt).

Nein, so was passiert, wenn jemand Namenloses faelschlich vermutet, den Sinn irgendwelcher zitierten Deklarationen verstanden zu haben.

Vinzent.

--
worst case: The wrong assumption there actually is one.
Reply to
Vinzent 'Gadget' Hoefler

Ich muss die passenden Linkerdeklarationen trotzdem selbst schreiben.

d

Weil mir das u.a. von den Koryphaeen in d.c.l.c erst vor kurzem so beigebracht wurde. :->

Ich weiss nicht, aber funktionierende Compiler fuer die Zielplattformen= , die ich brauche, existieren. Wo sie nicht existieren, gibt es notfalls Ada-nach-C-Konverter.

Das habe ich nicht getan. Ich habe lediglich dargelegt, warum ich es _gerade_ fuer hardwarenahe Programmierung fuer _besser_ geeignet halte als C. Und ich spreche da auch nicht ganz ohne Erfahrung.

Ist das eine Aufforderung, noch ein bisschen mehr zu erzaehlen? ;-)

Vinzent.

--=20 worst case: The wrong assumption there actually is one.

Reply to
Vinzent 'Gadget' Hoefler

Vinzent 'Gadget' Hoefler schrieb:

Nicht, wenn das Programmiersystem ordentlich gemacht worden ist.

Nu, ich habe mich kürzlich in die andere Richtung korrigieren lassen müssen und war selbst erstaunt, wie weit der Standard eigentlich die gängige Praxis unterstützt.

Dann hast du zu wenige Zielplattformen. ;-)

Da würde ich einigermaßen mitgehen, mit der Prämisse halt, dass es oft sehr viel länger dauert, bis es für eine Zielplattform eine Ada-Umgebung gibt, während C praktisch immer da ist.

--
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
Reply to
Joerg Wunsch

Vinzent 'Gadget' Hoefler schrieb:

Hör bitte mit *diesem* Niveau auf, sonst landest du sicher nicht nur in meinem Killfile.

Manfred kannst du kaum als ,,namenlos'' hinstellen, und jeder, der hier auch nur mehr als drei Tage mitgelesen hat weiß, dass MaWin einfach ein Symbol ist, sodass ihm praktisch jeder den Verstoß gegen die Netiquette verzeiht. Das heißt nicht, dass man mit dem fachlich (oder gar politisch, nicht wahr, Oli? ;-) immer einverstanden sein muss, was MaWin schreibt, aber zu den synonymbenutzenden Dummschwätzern gehört er weiß Gott nicht.

--
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
Reply to
Joerg Wunsch

Mal kurz zur Klaerung: Es wird von mir gemacht. Ich entscheide, welche Hardware mit welcher Adresse angesprochen wird, nicht irgendein Development-Kit irgendeines Mikroprozessor-Herstellers.

In diesem speziellen Fall sind also ich und der "Hersteller" des Programmiersystems gewissermassen identisch.

n
e

Tja, so kann man sich taeuschen. Lesen bildet (wie ich erst gestern wieder schmerzvoll feststellen durfte).

Ich glaube nicht. Eher zu wenig Zeit, alle auszuprobieren. :)

(Und sorry, aber jemand, der ernsthaft Bit-Felder in C verwendet, kann auch nicht allzuviele verschiedene Zielplattformen haben oder er hat Spass daran, sich die Deklarationen per #ifdef zurechtzubiegen.)

es oft

Wie gesagt, es gibt Ada-nach-C-Konverter. Und da Ada eine sehr strikt standardisierte Sprache ist, ist die Erfolgschance der Lauffaehigkeit des Produktes einer solchen Konvertierung ungleich hoeher als andersrum. ;->

Vinzent.

--=20 worst case: The wrong assumption there actually is one.

Reply to
Vinzent 'Gadget' Hoefler

Am Mon, 07 Feb 2005 18:52:15 +0100 hat Guido Grohmann geschrieben:

So schlimm ist es meistens nicht, aber eine Vollbremsung statt Kupplung ist fast immer drin :-) Obwohl Freunde, die mal mit meinem Auto fahren eh immer vorwarne, nicht zu kuppeln.

--
Martin
Reply to
Martin Lenz

es oft

Jedenfalls hast Du einige sinnvolle Meditationen geliefert, die das Nachvollziehen der Falschheit der Aussage

| Hardwarenahe Programmierung heist Kernel-Treiber schreiben und das | macht man nur in C/C++.

erm=F6glichen. Diese Aussage war wohl urspr=FCnglich auf HW-nahe=20 Programmierung f=FCr x86-PCs gem=FCnzt. Allerdings unterst=FCtzen=20 nichtmal dort alle C-Compiler so g=E4ngige CPU-Funktionalit=E4ten=20 wie bspw. MMX (schon gar nicht vollautomatisiert).

Na ja, wer Treiber f=FCr Linux oder Win schreiben muss, der wird wohl in der Tat zumindest ausschnittweise C ben=F6tigen, zumindest=20 um die OS-API bedienen zu k=F6nnen (in dem Bereich scheinen Tools,=20 die einem sowas ersparen, ja doch eher selten/teuer/unverf=FCgbar=20 zu sein). Auch das hat nix mit HW-, sondern vielmehr mit OS-N=E4he=20 zu tun.

Gemeint war wohl: < Hardwarenahe Programmierung hat manchmal einen Bezug zu=20 < Kernel-Treibern. Linux/Win-Kernel-Treiber werden f=FCr oft in C=20 < formuliert.

Gruss

Jan Bruns

Reply to
Jan Bruns

"Vinzent 'Gadget' Hoefler" schrieb im Newsbeitrag news: snipped-for-privacy@jellix.jlfencey.com...

Wer inhaltlich verloren hat, versucht's halt so, kennen wir schon.

Du darfst beruhigt akzeptieren, das an einer Programmiersprache wohl was oberfaul sein muss, wenn 4 Leute erst mal beim Lesen auf Anhieb in die Fallen tapsen, die diese Programmiersprache bietet. Dazu traegt auch bei, das niemand 16 KILOBYTE lesen will, wenn es ca. 13 Deklarationszeilen auch getan haetten wie in 'C'.

--
Manfred Winterhoff, reply-to invalid, use mawin at despammed.com
homepage: http://www.geocities.com/mwinterhoff/
de.sci.electronics FAQ: http://dse-faq.elektronik-kompendium.de/
Read 'Art of Electronics' Horowitz/Hill before you ask.
Lese 'Hohe Schule der Elektronik 1+2' bevor du fragst.
Reply to
MaWin

So rein prinzipiell kann ich Dir da nicht zustimmen...

Die "C-Header" und sonstigen Sachen werden von einem C-Compiler (auf Wuunsch) doch in 'normalen' Assembler umgewandelt, oder?

Und dann _könnte_ man auch gleich Makro's in Assembler schreiben. Oder sich (einmalig) der Mühe unterziehen, das in Äquivalente der benutzten Programmierspraceh umzuwandeln. Für 'perl' wurde sowas in frühen Linux-Distributionen während der Installation von perl durchgeführt.

Das mag an der potentiellen Nutzerzahl liegen; 'AngebotNachfrage' Es gibt auf jeden fall eine Möglichkeit, unter Linux in Assembler zu arbeiten

Nicht prinzipiell. Einen OS-Aufruf könnte man auch mit einer Turing-Maschine machen, oder? :-)

Gruss, Holger

Reply to
Holger Petersen

"Andreas Schwarz" schrieb im Newsbeitrag news:4206679d$0$18566$ snipped-for-privacy@newsread4.arcor-online.net...

Aber sehr wohl.

Papierschere, Blechschere, ZickZackSchere hat man auch in der Realitaet, aus gutem Grund. Schon alleine, weil es beim Schreiben eines Buches abnervt, wenn der Stift staendig unter der nie benoetigten Schere liegt.

Weil tausende Jahre Erfahrung der Menschheit zeigen, das das kein tragfaehiges Konzept ist. Ich will nicht alle bereits beschriebene un in einem Ordner abgehefteten Papiere aendern, bloss weil ich bei EINEM neuen Papier einen Kreis schneiden will.

Natuerlich ist das geschilderete auch kein MVC, entgegen Axels Vermutung:

formatting link

--
Manfred Winterhoff, reply-to invalid, use mawin at despammed.com
homepage: http://www.geocities.com/mwinterhoff/
de.sci.electronics FAQ: http://dse-faq.elektronik-kompendium.de/
Read 'Art of Electronics' Horowitz/Hill before you ask.
Lese 'Hohe Schule der Elektronik 1+2' bevor du fragst.
Reply to
MaWin

"Holger Petersen":

=20

=20

Klar. Ist rein prinzipiell auch verkehrt. =20

Sch=F6n w=E4r's ja. So ist es aber leider nicht.

#define HOCHWICHTIGESZEUGS konkretes Ding #ifdef IRGENDWOAUSMAKEFILE #define such_mich_special konkret1 #else #define such_mich_special konkret2 #endif #define unwichtig(p1) SUPERWICHTIGABERAUSUNBEKANNTERDATEI(p1)

compiliert zur leeren Menge, ergibt auch bereits nach dem Macro-replacement ein leeres Ergebnis.

Nat=FCrlich *k=F6nnte* man das, wenn

1.) die Header =FCberhaupt zur Verf=FCgung stehen bei MS gibt's das DDK neuerdings nur noch gegen *viel* Bares 2.) die Header keine undokumentierten compilerspezifischen=20 Konstrukte verwenden (ist das Speicherabbild echter C++ Interfaces offiziell dokumentiert?) 3.) der Aufwand lohnt (DriverPI !=3D vielgenutzte API) 4.) die Zielsprache entsprechende Konstrukte unterst=FCtzt

Vollautomatisch funktioniert das in der Praxis nicht.

So unterst=FCtzt z.B. der freepascal Pr=E4processor nicht s=E4mtliche C-Pr=E4prozessor-Konstrukte. Verbleibt also die M=F6glichkeit, defines zu Konstanten zu =FCbersetzen. Konstanten d=FCrfen aber (im Gegensatz zu C-defines) nicht umdefiniert werden (ist in C mit vorherigem undefine erlaubt; MS macht =FCbrigens intensiven=20 Gebrauch von diesem "Trick").

Weitere Probleme tauchen auf, wenn die =DCbersetzung eine "Konstrukterkennung" implementieren m=FCsste. Unsch=F6nes Beispiel aus "dsound.h": ___________________________________________________

#undef INTERFACE #define INTERFACE IReferenceClock DECLARE_INTERFACE_(IReferenceClock, IUnknown) { STDMETHOD(QueryInterface) (THIS_ REFIID, LPVOID *) PURE; STDMETHOD_(ULONG,AddRef) (THIS) PURE; STDMETHOD_(ULONG,Release) (THIS) PURE; STDMETHOD(GetTime) (THIS_ REFERENCE_TIME *pTime) PURE; [...] }; #endif // __IReferenceClock_INTERFACE_DEFINED__ #ifndef IReferenceClock_QueryInterface #define IReferenceClock_QueryInterface(p,a,b) = IUnknown_QueryInterface(p,a,b) #define IReferenceClock_AddRef(p) IUnknown_AddRef(p) #define IReferenceClock_Release(p) IUnknown_Release(p) #if !defined(__cplusplus) || defined(CINTERFACE) #define IReferenceClock_GetTime(p,a) (p)->lpVtbl->GetTime(p,a) [...] #else // !defined(__cplusplus) || defined(CINTERFACE) #define IReferenceClock_GetTime(p,a) (p)->GetTime(a) [...] #endif // !defined(__cplusplus) || defined(CINTERFACE) #endif // IReferenceClock_QueryInterface ____________________________________________________

sollte eigentlich m=F6glichst =FCbersetzt werden zu ungef=E4hr:

____________________________________________________

TYPE=20 IReferenceClock_GetTime =3D FUNCTION(p_REFERENCE_TIME) : ULONG;

IReferenceClock_functionpointerlist =3D packed record QueryInterface, AddRef, Release,... : egal; GetTime : IReferenceClock_GetTime; end;

IReferenceClock =3D object f : ^IReferenceClock_functionpointerlist; FUNCTION GetTime(pTime : p_REFERENCE_TIME) : ULONG; constructor init; destructor kill; end;

FUNCTION IReferenceClock.GetTime(pTime : p_REFERENCE_TIME) : ULONG; BEGIN GetTime :=3D f^.Gettime(pTime); END;

constructor IReferenceClock.init; BEGIN END; ... ____________________________________________________

PROGRAM bsp; uses dsound;

VAR=20 refclk_parent : ???; refclk : IReferenceClock; ptim : REFERENCE_TIME;

BEGIN ... refclk_parent.create_refclk(refclk); refclk.GetTime(@ptim); //no errorchecking, yet writeln(ptim); END.

____________________________________________________

=20

=20

Ist dabei aber immer darauf angewiesen, da=DF irgendjemand bereits Makros f=FCr den jeweils gew=FCnschten syscall geschrieben hat. =20 Gruss

Jan Bruns

Reply to
Jan Bruns

Vererbung.

Ähem. Wie hast du denn dieses historische Dokument gefunden?

Aber MVC ist ein *Konzept*. Keine Schritt-für-Schritt-Anleitung, an die man sich sklavisch halten muß, sondern ein Designprinzip. Ein wesentliches Ziel von MVC ist Trennung von (G)UI und Logik.

formatting link

XL

Reply to
Axel Schwenke

Das hoffe ich doch. Immerhin wuerde der Beweis der Korrektheit obiger Aussage meine Existenz an sich in Frage stellen. ;)

BTW, Dinge wie

apicdef.h: |#define APIC_EIO_ACK 0x0 /* Write this to the EOI register */

scheinbar ein Tippfehler, der evt. ein Grund fuer

apic.h: |/* Docs say use 0 for future compatibility */ |apic_write_around(APIC_EOI, 0);

sein koennte,

lassen mich dann doch daran zweifeln, ob C fuer hardwarenahe Programmierung tatsaechlich so gut geeignet ist. (Der Sinn der Deklaration von Konstanten, um sie dann im geeigneten Moment nicht zu benutzen, erschliesst sich mir nicht.)

Selbst da wuerde sie nicht stimmen.

Ja. Du hast die Gruende, warum man Schnittstellen einer C-API zu andere= n Sprachen praktisch nur per Hand machen kann, ja mindestens ansatzweise schon gezeigt. Das ist muehsam und fuer einen Treiber, der in der Groessenordnung von ueblicherweise kaum mehr als 1 bis 2 kSLOC liegt, einfach zu aufwendig. In der Zeit, die man zum Konvertieren passender Header benoetigt, hat man den C-Code auch ausreichend entwanzt. ;-)

Es ist fuer so ein Tool in der Praxis faktisch unmoeglich, aus uebliche= n C-Headern /brauchbare/ Deklarationen zu entwickeln.

Ja.

Das waere weniger inkorrekt gewesen, ja.

Vinzent.

--=20 worst case: The wrong assumption there actually is one.

Reply to
Vinzent 'Gadget' Hoefler

Hmm, aber das widerspricht der Aussage, bei C wären die int-to-pointer-casts undefined, denn der Ada-nach-C-Konverter muß ja genau darauf aufbauen. In logischer Konsequenz könnten dann nämlich nicht alle Ada-Konstrukte abgebildet werden.

Bernd

Reply to
Bernd Laengerich

Hmm, bei europäischen Autos mit Autmakatikgetriebe ist das Bremspedal aber doch nicht so breit wie bei den Amis. Ich trat da bisher immer ins Leere, wenn ich mal nicht dran dachte. Auch die rechte Hand fiel manchmal herunter (Toyota Previa Automatik mit Lenkradschaltung) :-)

Bernd

Reply to
Bernd Laengerich

Hmm, nein. Wir haben uns ja mittlerweile auf "implementation-defined" geeinigt. :)

ch

Das iSv. "alle" kann man im allgemeinen ohnehin nicht (direkt). Bei protected types z.B. kann man sich notfalls mit "selbstgebastelten" Semaphoren behelfen, spaetestens beim Tasking musst Du es irgendwie auch die zur Verfuegung stehende Laufzeitbibliothek mappen. Mit Standard-C kommst Du da nicht mehr allzuweit.

Vinzent.

--=20 worst case: The wrong assumption there actually is one.

Reply to
Vinzent 'Gadget' Hoefler

Am Wed, 09 Feb 2005 10:19:02 +0100 hat Bernd Laengerich geschrieben:

Japaner (Honda Accord), ich würde sagen 1,5 mal so breit wie bei manueller Schaltung. Manche habens halt gefunden, wenn sie "verzweifelt" die Kupplung gesucht haben. :-) Ist aber zum Glück nie was passiert.

--
Martin
Reply to
Martin Lenz

Na denn... :)

Es ging mir nur um Sprachkonstrukte, nicht um Libs. Von Ada habe ich aber keine Ahnung. Sprachen die eine Runtime Lib vorraussetzen (wie Pascal), finde ich irgendwie für Hardwaresachen ungeeignet.

Bernd

Reply to
Bernd Laengerich

Ein Freund (hallo Jorgen!) hatte mal zwei quasi identische Autos: Kadett, beide gleiche Farbe, gleiches Interieur etc., nur einer Schaltung und einer Automatik...

Bernd

Reply to
Bernd Laengerich

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.