Übersetzung des Lazarus-Wiki

Für Dinge rund um die Unterstützung des offizielen Lazarusprojekts, wie Übersetzungsabsprachen und anderem.
Antworten
Euklid
Lazarusforum e. V.
Beiträge: 2808
Registriert: Fr 22. Sep 2006, 10:38
OS, Lazarus, FPC: Lazarus v2.0.10, FPC 3.2.0
Wohnort: Hessen
Kontaktdaten:

Beitrag von Euklid »

Teilweise haben die da aber auch Sätze im Englischen, die meiner Meinung nach keinen Sinn machen.

Wie würdet Ihr folgenden Satz übersetzen?

On windows 20k WinAPI GUI using binaries are no problem.


Habe ihn mal so übersetzt:
Unter Windows ist es kein Problem, die Windows API benutzende Binärdateien zu erstellen, die nur 20 Kb groß sind.

Was sagt ihr?

Oder der ganze Absatz zur Frage "what are current realistic sizes for Free Pascal/Lazarus binaries?"

With small apps it is a bit harder. This is because RTL size is OS dependant. However 100k standalone binaries that do something can be done, usually even below 50k.

* On windows 20k WinAPI GUI using binaries are no problem.
* Unit Sysutils contains internationalisation, textual errormessages, and exception handling and some other stuff that is always linked in when this unit is used (think 40-100k total).


"Mit kleinen Anwendungen ist es ein bisschen härter. Weil die Größe der RTL Systemabhängig ist." - Die Antwort passt doch garnicht zur Frage! Wie ist sie überhaupt gemeint? Habe sie mal übersetzt zu:

"Bei kleinen Anwendungen spielt die Systemabhängigkeit der Größe der RTL eine gewichtigere Rolle."
Zuletzt geändert von Euklid am Mo 22. Jan 2007, 22:04, insgesamt 1-mal geändert.

Christian
Beiträge: 6079
Registriert: Do 21. Sep 2006, 07:51
OS, Lazarus, FPC: iWinux (L 1.x.xy FPC 2.y.z)
CPU-Target: AVR,ARM,x86(-64)
Wohnort: Dessau
Kontaktdaten:

Beitrag von Christian »

Gemeint ist hier sicherlich das Windows 2K (2000) API ...
W.m.k.A.h.e.m.F.h. -> http://www.gidf.de/

Euklid
Lazarusforum e. V.
Beiträge: 2808
Registriert: Fr 22. Sep 2006, 10:38
OS, Lazarus, FPC: Lazarus v2.0.10, FPC 3.2.0
Wohnort: Hessen
Kontaktdaten:

Beitrag von Euklid »

Hallo! Habe da mal ne Frage:

Was ist mit "the embedded programming world" gemeint?
Oder allgemein: Was ist embedded programming?

Christian
Beiträge: 6079
Registriert: Do 21. Sep 2006, 07:51
OS, Lazarus, FPC: iWinux (L 1.x.xy FPC 2.y.z)
CPU-Target: AVR,ARM,x86(-64)
Wohnort: Dessau
Kontaktdaten:

Beitrag von Christian »

Embedded Systems sind intigrierte Systeme also Kleinscomputer (PDAś telefone Waschmascheinen Toaster :p)
Embedded programming ist danach die programmierung solcher Systeme und "The Embedded World" würd ich frei mit "Die Mobile Welt" übersetzen
W.m.k.A.h.e.m.F.h. -> http://www.gidf.de/

Euklid
Lazarusforum e. V.
Beiträge: 2808
Registriert: Fr 22. Sep 2006, 10:38
OS, Lazarus, FPC: Lazarus v2.0.10, FPC 3.2.0
Wohnort: Hessen
Kontaktdaten:

Beitrag von Euklid »

Ahh. Gut. Dann macht das ganze Sinn. Danke für die Antwort

schnullerbacke
Beiträge: 1187
Registriert: Mi 13. Dez 2006, 10:58
OS, Lazarus, FPC: Winux (L 1.2.xy FPC 2.6.z)
CPU-Target: AMD A4-6400 APU
Wohnort: Hamburg

Beitrag von schnullerbacke »

Im Zusammenhang mit FPC/Lazarus sollte mit "embedded programming" eher eine Library gemeint sein, mit der man speziellen Code für bestimmte Geräte erzeugen kann (siehe embedded SQL). Die Library entspricht dabei i.d.R. einem Präprozessor, der die spezialisierten Befehle in entsprechenden Binärcode wandelt, damit das Gerät mit seinen speziellen Befehlen angesprochen werden kann. Die meisten dieser Geräte verfügen meist nicht über einen Prozessor sondern über einen Controler.

Controler verfügen über einen eingeschränkten Registersatz und deshalb auch meistens nur eine RISC-Befehlssatz. Man kann mit Controlern auch rechnen obwohl diese nicht über einen Akkumulator verfügen. Anstatt nun einen speziellen Assembler für diese Controler zu benutzen, kann man über den Präprozessor diese Befehle direkt im Pascal-Quellcode angeben und der Präprozessor erzeugt dann den Assembler-Code und daraus wird dann der passende Binärcode für den Controler produziert.

Dabei kann der Controler auch virtuell sein (siehe SQL).

Als Beispiel für embedded Systeme kann man sich den Firebird embedded Server nehmen. Der kann in ein Pascal-Programm eingebunden werden und das Programm hat seinen eigenen Datenbank-Server für seine Daten. Allerdings darf neben dem Firebird embedded kein echter Firebird SQL-Server installiert sein. Wohl aber können mehrere Programme auf einer Maschine ihren eigenen embedded-Server starten.

Ein anderes Beispiel für embedded sind die Lib's für Terminplaner. Sie stellen die Schnittstellen bereit um Daten aus dem Terminplaner zu lesen oder neue Daten einzufügen. Bei sehr guten Präprozessoren kann man auch neue Software für den Terminplaner auf seiner Maschine erzeugen und diese später im Terminplaner installieren.

Vereinfacht kann man das auch Crossplatform-Development bezeichnen. Beispiel dafür sind SPS, SQL, Terminplaner und besondere Präprozessoren für Microcontroler. Also ein ziemlich weites Feld.
Humor ist der Knopf, der verhindert, daß uns der Kragen platzt.

(Ringelnatz)

Christian
Beiträge: 6079
Registriert: Do 21. Sep 2006, 07:51
OS, Lazarus, FPC: iWinux (L 1.x.xy FPC 2.y.z)
CPU-Target: AVR,ARM,x86(-64)
Wohnort: Dessau
Kontaktdaten:

Beitrag von Christian »

Irgendwie macht der text für mich überhaupt keinen Sinn Ich kann auch nicht zuordnen was da jetzt schiefgegangen ist.
Ich kenn mich mit Embedded SQL nicht aus.
embedded programming" eher eine Library gemeint sein, mit der man speziellen Code für bestimmte Geräte erzeugen kann (siehe embedded SQL).

Aber ein Gerät ist für mich immer Hardware.

Ich kenn keinen Controller ohne Akkumulator das ist eigentlich das Herz eines Controllers. Und ich denke ich kenn mich mit Hardwareentwicklung n bissle aus da ich das seit etlichen Jahren beruflich mache. Wir arbeiten hier auch permanent mir Mikrocontrollern aber ohne Akku gibt es höchstens Logikbausteine die natürlich nicht Programmierbar sind.

Die Wiki sagt zum embedded SQL
* Beim eingebetteten SQL (engl. embedded SQL) wird eine Programmiersprache im Quelltext um gekennzeichnete SQL-Anweisungen erweitert. Während der Programmvorbereitung übersetzt ein Precompiler die SQL-Befehle in Funktionsaufrufe. Beispiele: Embedded SQL nach ANSI, SQLJ für Java.
* Herkömmliche (API-)Programmierschnittstellen erlauben die direkte Übergabe von SQL-Befehlen an Datenbanksysteme über Funktionsaufrufe. Beispiele: ODBC, JDBC.


was für mich dann wieder sinn macht aber sicher nichts mit der Übersetzung von Euklid zu tun hat. Wo kommen jetzt die Controller her ?
W.m.k.A.h.e.m.F.h. -> http://www.gidf.de/

schnullerbacke
Beiträge: 1187
Registriert: Mi 13. Dez 2006, 10:58
OS, Lazarus, FPC: Winux (L 1.2.xy FPC 2.6.z)
CPU-Target: AMD A4-6400 APU
Wohnort: Hamburg

Beitrag von schnullerbacke »

Microcontroler verfügen im Gegensatz zu Prozessoren eben nicht über den Akku, das macht gerade den Unterschied aus. Ich hab jahrelang bei Phillips-Components gearbeitet. Da wurden vornehmlich Microcontroler gefertigt (bis auf ein paar Sonderformen des M 680XX).

Mag ja sein, das inzwischen der eine oder andere Microcontroler über einen Akku verfügt, streng genommen ist es dann aber ein Prozessor.

Gemeinsam ist beiden aber die Anwesenheit von Registern (auch Flag-Register). Niemand hindert einen daran, bestimmte Register des Controlers zum rechnen zu benutzen. Der Nachteil besteht darin, das man die entsprechende Mathematik "Schritt für Schritt" abarbeiten, also programmieren, muß. Embedded-Präprozessoren nehmen dir diese lästige Prozedur ab und bauen deinen Code für den Microcontroler entsprechend um.

Bei Embedded-SQL kannst du im Pascal-Code so etwas in dieser Art machen:

Code: Alles auswählen

procedure BlaBla(args);
begin
   SQLExecute
     SELECT * FROM tablename
     WHERE {expression};
   EndSQL;
end;


Der Präprozessor wird dann bei SQLExecute beim kompilieren aufgerufen und setzt die Befehle bis EndSQL in den entsprechenden Binärcode für den SQL embedded-Server um. Der wird dann im fertigen Programm direkt auf dem SQL-Server ausgeführt, der Umweg über eine Library wie etwa ZeosDBO oder ähnlich entfällt damit.

Das gleiche Spiel kann man auch für Microcontroler machen. Die ersten Präprozessoren waren damals für SPS weit verbreitet. Du hast dein SPS-Programm auf nem normalen PC entwickelt und gestestet und es dann in den SPS-Controler übertragen. Der enthielt für sich ebenfalls einen Microcontroler der das Programm dann ausgeführt hat. Einen Akku brauchte der dafür jedenfalls nicht, wohl aber die entsprechenden Register um zum einen das Programm aus dem Flashprom zu laden und seine Daten in diesen zu schreiben.

Ein Beispiel für solche Microcontroler hat jeder vor sich rumstehen, der einen Komputel sein eigen nennt. Die Tastatur vor unserer Nase wird von einem Microcontroler gesteuert. Bei entsprechender Bauweise und Microcontroler kann die Tastatur auch programmierbar sein ohne das deswegen gleich ein Akku nötig wäre.

Schließlich hat der Akku gegenüber den anderen Registern nur den Vorteil, das er halt addieren und subtrahieren kann. Bei entsprechendem ROM-Code auch multiplizieren und dividieren. Das geht aber ohne den ROM-Code auch mit den normalen Registern. Nur halt aufwendiger.
Humor ist der Knopf, der verhindert, daß uns der Kragen platzt.

(Ringelnatz)

mschnell
Beiträge: 3444
Registriert: Mo 11. Sep 2006, 10:24
OS, Lazarus, FPC: svn (Window32, Linux x64, Linux ARM (QNAP) (cross+nativ)
CPU-Target: X32 / X64 / ARMv5
Wohnort: Krefeld

Beitrag von mschnell »

Christian hat geschrieben:Embedded Systems sind intigrierte Systeme also Kleinscomputer (PDAś telefone Waschmascheinen Toaster :p)
Embedded programming ist danach die programmierung solcher Systeme und "The Embedded World" würd ich frei mit "Die Mobile Welt" übersetzen


Einspruch !

Ich mache hier großenteils embedded Kram und meiner Ansicht nach ist die Definition anders.

Das Haupt-Kriterium für ein embedded System ist, das da kein Benutzer dran sitzt, der das Programm startet und beendet.

Viele Embedded System sind demzufolge voll automatisch und gar nicht sichtbar. (z.B. Heizungssteuerung).

Es kann durchaus ein Benutzer dran sitzen, der erkennt aber kein Programm oder gar ein Betriebssystem. (z.B. Handy).

Untypisch (aber nicht unmöglich) sind "normale" Bildschirme und Tastaturen.

Nicht notwendig aber oft verlangt ist harte Realtime-Fähigkeit (was heißt eine Aufgabe muss zwingend in einer bestimmten Zeit erledigt sein, damit keine Katastrophen passieren).

Nicht notwendig aber oft verlangt ist geringe Größe, geringer Stromverbrauch, geringe Kosten etc.

"Embedded World" ist dann "Welt der eingebetteten System".

-Michael

Christian
Beiträge: 6079
Registriert: Do 21. Sep 2006, 07:51
OS, Lazarus, FPC: iWinux (L 1.x.xy FPC 2.y.z)
CPU-Target: AVR,ARM,x86(-64)
Wohnort: Dessau
Kontaktdaten:

Beitrag von Christian »

Microcontroler verfügen im Gegensatz zu Prozessoren eben nicht über den Akku, das macht gerade den Unterschied aus. Ich hab jahrelang bei Phillips-Components gearbeitet. Da wurden vornehmlich Microcontroler gefertigt (bis auf ein paar Sonderformen des M 680XX).

Mag ja sein, das inzwischen der eine oder andere Microcontroler über einen Akku verfügt, streng genommen ist es dann aber ein Prozessor.


Es ist technisch nicht möglich einen Controller jeglicher Art ohne Akku zu bauen Alles was Programmierbar ist hat auch einen Akku die ALU basiert darauf und ohne diese sind keine Mathematischen Operationen möglich. Nicht der eine oder andere ...
Der Unterscheid zwischen Prozessor und Microcontroller ist das beim Microcontroller alles intigriert ist (embedded) es ist ein Embedded System wobei wir wieder beim Stichwort wären Speicher, Prozessor, Schnittstellen ist halt alles in einem Gehäuse intigriert das macht es zum Mikrocontroller.

Informationslektüre:

http://de.wikipedia.org/wiki/Arithmetic_Logical_Unit
http://de.wikipedia.org/wiki/Mikrocontroller
W.m.k.A.h.e.m.F.h. -> http://www.gidf.de/

Christian
Beiträge: 6079
Registriert: Do 21. Sep 2006, 07:51
OS, Lazarus, FPC: iWinux (L 1.x.xy FPC 2.y.z)
CPU-Target: AVR,ARM,x86(-64)
Wohnort: Dessau
Kontaktdaten:

Beitrag von Christian »

@michael hast recht aber nicht uneingeschränkt embedded systems haben auch benutzerschnittstellen ich verweise heir mal auf den wiki artikel
http://de.wikipedia.org/wiki/Embedded_System um dem streit zu entgehen
W.m.k.A.h.e.m.F.h. -> http://www.gidf.de/

schnullerbacke
Beiträge: 1187
Registriert: Mi 13. Dez 2006, 10:58
OS, Lazarus, FPC: Winux (L 1.2.xy FPC 2.6.z)
CPU-Target: AMD A4-6400 APU
Wohnort: Hamburg

Beitrag von schnullerbacke »

Da müssen dann wohl alle Professoren an der FH-Hamburg in den 80zigern völlig verblödet gewesen sein als sie uns die Binärarythmetik beigepult haben und dabei gleichzeitig bewiesen haben, das man keine ALU braucht um die Funktionen auch auf einem Controler ohne ALU basteln kann. Jedenfalls war das bei den Motorola-Controlern leicht möglich, weil die eben mit linearen Adressen gearbeit haben.

Niemand kann mich hindern auf eine Speicheradresse zuzugreifen, das ist ganzzahlig und durch Manipulation auf dem Register möglich. Lediglich der Zugriff auf bestimmte Speicherstellen ist nötig um das Datum in das Register zu laden. Wenn man's auf die Spitze treiben will, kann man auch floating point realisieren. Behauptet ja niemand, das sowas einfach wäre, aber machbar ist es. Bitweise schieben ist das einzige was man dafür braucht, ne ALU ist dazu nicht nötig, die macht es nur bequemer. Die nimmt einem die Behandlung von Überläufen und ähnlichem ab und setzt die Flags, das kann man aber auch selbst prüfen und das Flag setzen.

Allerdings hatten diese My-C's für die Speicheradressierung reservierte Register, die man besser nicht für was anderes verwendet hat. Alle anderen bis auf Flag durften beliebig benutzt werden.

Nun kann man kleinlich werden und behaupten, für bitweise Schieben wäre schon ne ALU fällig. Aber man kann auch päpstlicher werden als der Papst. Und schließlich kann man den ganzen Käse auch diskret mit Operationsverstärkern basteln, nur wer macht das heute noch?
Humor ist der Knopf, der verhindert, daß uns der Kragen platzt.

(Ringelnatz)

Christian
Beiträge: 6079
Registriert: Do 21. Sep 2006, 07:51
OS, Lazarus, FPC: iWinux (L 1.x.xy FPC 2.y.z)
CPU-Target: AVR,ARM,x86(-64)
Wohnort: Dessau
Kontaktdaten:

Beitrag von Christian »

Nur mit Bitschiebereien sind doch aber ekien Rechenoperationen möglich jedenfalls keine Addition und Subtraktion und damit auch nur sehr eingeschränkt eine Multiplikation Ich kann mir das nicht vorstellen hast du mal nen Controllertyp für mich ? Das Datenblatt hätt ich gern gesehn.
W.m.k.A.h.e.m.F.h. -> http://www.gidf.de/

schnullerbacke
Beiträge: 1187
Registriert: Mi 13. Dez 2006, 10:58
OS, Lazarus, FPC: Winux (L 1.2.xy FPC 2.6.z)
CPU-Target: AMD A4-6400 APU
Wohnort: Hamburg

Beitrag von schnullerbacke »

Oha, das ist 20 Jahre her. Frag mich mal wie die damals hießen? Jedenfalls hatten wir für die Dinger nen Cross-Assembler. Du konntest auf nem Intelprozessor Assemblercode für die 680x0-Serie erstellen und testen. Bei den Controlern mußte man allerdings selbst auf das reduzierte instructionset achten. Wenn's fertig war konnte man das dann aber auf dem Controler ablaufen lassen.

Ums einfacher auzudrücken, du mußtest dir halt ne Soft-ALU bauen. Das machte damals auch Sinn. Die ALU's hatten bei der Fertigung reichlich Probleme und haben die meisten Ausfälle produziert, ähnliches galt für den ROM-Code.

Die einzigen Register auf denen Addition und Subtraktion ging waren der Programmzähler und das Datenregister, die 2 waren reserviert. Man konnte auf denen zwar sowas machen, dafür mußte man aber aufpassen wie ein Schießhund. Dann gab es 6 oder 7 weitere Register neben den beiden und Flag. Die hatten aber nur einfache Schiebebefehle zur Verfügung. Kein branch prediction kein nix nicht. Wenn du also 2 Register addieren wolltest, dann hast du in einer Schleife Rechtsschieben auf beide angewendet und dann das Schiebeflag verglichen, nach dem Muster:

1 + 1 = 0 plus 1 ins Kröpfchen

dann wieder schieben und den Übertrag dazu. Zuletzt das ganze verglichen und Übertrag gesetzt wenn ne 1 übrig blieb. Im 3ten Register stand dann das Zwischenergebnis. Für nen 4byte-Integer also das ganze Gemüse 2 mal gemacht wenn du 16-bit Register hattest. Mühsam und sehr fehleranfällig aber möglich. Divison und Multiplikation konnte man auch machen, war aber noch komplizierter. Letztlich ist ne Multiplikation ja nichts weiter als eine fortgesetzte Addition (Divison entspricht dann der Subtraktion). Läßt sich also alles auf ne Grundrechenart zurück führen.
Humor ist der Knopf, der verhindert, daß uns der Kragen platzt.

(Ringelnatz)

Christian
Beiträge: 6079
Registriert: Do 21. Sep 2006, 07:51
OS, Lazarus, FPC: iWinux (L 1.x.xy FPC 2.y.z)
CPU-Target: AVR,ARM,x86(-64)
Wohnort: Dessau
Kontaktdaten:

Beitrag von Christian »

Ach so, dann hatte man doch aber trotsdem schon ne einfache alu und dein "datenregister" ist nach der definition die ich kenne ein akku ...
Und die 68K Serie von Motorola fals wir von der reden hatte durchaus eine ALU mit der man auch direkt Addieren Subtrahieren Multiplizieren und dividieren kann wird übrigends vom fpc 2.1.1 wieder unterstützt :p
W.m.k.A.h.e.m.F.h. -> http://www.gidf.de/

Antworten