Und noch eine konkretere Frage:
folgendes steht auf der GNU-bash-Seite:
-- Begin
Bash is an sh-compatible shell that incorporates useful features from the Korn
shell (ksh) and C shell (csh) . It is intended to conform to the IEEE POSIX
P1003.2/ISO 9945.2 Shell and Tools standard .
-- End
In wie fern ist dieses "indended" den umgesetzt? Wo happert es noch? Was sind
die Schwierigkeiten/Tüken der POSIX-Konformität
--
Alles Gute kommt durch die Leitung.
> In den letzten Tagen ist mir POSIX, BOURNE usw. nur so um die Ohren
> geflogen... Was ist das? Bzw. wo kann ich nachlesen was das ist?
POSIX steht für 'Portable Operating System Interface Specification'
oder so ähnlich. POSIX ist eine Reihe von Dokumenten, die diverse
Schnittstellen eines UNIX-ähnlichen Systems beschreiben (APIs für C
und Ada, die Shell usw.). POSIX verfolgt dabei teilweise einen recht
minimalistischen Ansatz. Ein System mit POSIX-Semantik verhält sich
i.a. noch nicht wie ein UNIX-System.
> -- Begin
> Bash is an sh-compatible shell that incorporates useful features from the Korn
> shell (ksh) and C shell (csh) . It is intended to conform to the IEEE POSIX
> P1003.2/ISO 9945.2 Shell and Tools standard .
> -- End
>
> In wie fern ist dieses "indended" den umgesetzt?
Es gibt zumindest eine ganze Reihe theoretisch inkompatibler Erweiterungen.
> Wo happert es noch? Was sind die Schwierigkeiten/Tüken der
> POSIX-Konformität
POSIX kennt einige Dinge nicht, die man heutzutage zu den Fähigkeiten
unixoider Systeme rechnet (z.B. Symlinks).
> In den letzten Tagen ist mir POSIX, BOURNE usw. nur so um die Ohren
> geflogen...
> Was ist das? Bzw. wo kann ich nachlesen was das ist?
>
> Und noch eine konkretere Frage:
> folgendes steht auf der GNU-bash-Seite: [...]
Das können wir mit einer Klappe erschlagen: BASH FAQ, Punkte A9 und A10.
http://www.landfield.com/faqs/unix-faq/shell/bash/
> Was sind die Schwierigkeiten/Tücken der POSIX-Konformität?
Sporadisch muss man unterscheiden zwischen dem, was in einer
POSIX-Norm wirklich steht, was gemeint war, und was sinnvoll ist.
Eine offizielle POSIX-Zertifizierung kostet Geld.
--
Christian "naddy" Weisgerber na...@mips.inka.de
Florian Weimer wrote:
>
> POSIX verfolgt dabei teilweise einen recht
> minimalistischen Ansatz. Ein System mit POSIX-Semantik verhält sich
> i.a. noch nicht wie ein UNIX-System.
Nein, natürlich nicht. OpenVMS und Teile von WinNT sind z.B. auch
POSIX konform, aber das sind sicher keine Unix Systeme.
mfg
Dennis
--
Q: How can I open an iMac?
A: I used a saw.
Heisst es das die Entwicklung/Anpassung von POSIX nicht mehr vorangetrieben
wird? Lohnt sich denn so ein Standpunkt als Standard? Und warum ist dieser
nicht frei verfügbar? Damit wird doch nur die Verbreitung erschwert, und viele
programmieren dann nicht POSIX-konform?
BTW: wieviel Aufwendungen (Zeit/Geld) kostet es sich diese Doku zu besorgen
und welchen Umfang hat sie?
Zumindest die (schwachen zugegeben) Fragen sind damit "erschalgen" ;)
> > Was sind die Schwierigkeiten/Tücken der POSIX-Konformität?
> Sporadisch muss man unterscheiden zwischen dem, was in einer
> POSIX-Norm wirklich steht, was gemeint war, und was sinnvoll ist.
Womit man nach einigen Überlegungen bei der Frage landet:
In wie fern ist dieser Standard verbreitet ohne dass hier und da mal eben
kleine Unterschiede in der Implementierung sind (Sprich gibt es bug-freie
Referenz-Implementierungen in Form von Shell/Tools)? Ist POSIX denn überhaupt
der kleinste gemeinsame Nenner von *Xen? Wenn nicht was ist es dann
(vielleicht differenziert betrachtet in Zonen wie hier in der Gruppe,
Deutschland, Europa, Amerika, Welt)? Gibt es Alternativen zu POSIX (ev. freier
Natur)?
Müssen ja auch konform zu POSIX sein. Das ist ein Kriterium
amerikanischer Behörden.
Ohne POSIX kein Windows NT auf einem Kriegsschiff. :-}
Posix wird von der Austin-Group (www.opengroup.org) weiterentwickelt.
POSIX besteht aus mehreren Standards, Part 1 (ISO/IEC 9945-1 -
ANSI/IEEE Std. 1003.1) hat 784 Seiten und kostet ca. 300 DM und kann
via DIN online bestellt werden.
Wenn Du was freies haben willst, dann hol Dir die Unix95 Doku, die auf
POSIX aufsetzt.
Andreas
--
Andreas Jaeger
SuSE Labs a...@suse.de
private a...@arthur.inka.de
http://www.suse.de/~aj
POSIX diente ursprünglich auch nicht dazu, nur die Unix-Systeme
unter einen Hut zu bringen, obwohl es von diesen natürlich schwer
beeinflußt wurde. Es wollte noch übergreifender sein.
Deshalb wirkt es auch so minimalistisch, weil einige Funktionen
fehlen, die so nur unter Unixen möglich sind.
Z.B. ist "fork" genau wie Symlinks kein Bestandteil von
POSIX, sondern man findet allenfalls "vfork".
fork läßt sich unter Systemen wie VMS, MVS oder NT
kaum implementieren ohne das ganze System umzukrempeln,
vfork dagegen schon.
Der Name stammt angeblich von RMS höchstselbst.
Gruss,
Christian
Darum sind diese auch POSIX-zertifiziert, die meisten Unices aber
nicht. Das veranlaßt den einen oder anderen "Reverend", be*** Flame-Threads
in die Welt zu setzen (comp.unix.bsd.freebsd.misc). In der Sache
hat Posix das "Problem", nämlich die bekannte Spaltung in SysV und
BSD, verschlimmbessert, indem eine weitere Sekte gegründet wurde.
Und nun haben wir auch noch Linux mit den Untersekten RH, SuSe, Debian & Co.
Nur leider keinen technischen Fortschritt mehr.
--
Dipl.-Math. Wilhelm Bernhard Kloke
Institut fuer Arbeitsphysiologie an der Universitaet Dortmund
Ardeystrasse 67, D-44139 Dortmund, Tel. 0231-1084-257
> In der Sache hat Posix das "Problem", nämlich die bekannte Spaltung
> in SysV und BSD, verschlimmbessert, indem eine weitere Sekte
> gegründet wurde.
So kann man das nicht sagen, da POSIX ja wirklich nur eine Art
kleinsten gemeinsamen Nenner darstellt, auf den sich die »gespaltenen«
Systeme gerade noch einigen konnten. Das Problem mit POSIX ist eher,
daß viele Sachen, die man für »interessante« Programme braucht, eben
*nicht* standardisiert wurden, da man sich nicht auf eine der beiden
Schienen festlegen wollte (Stichwort: select() vs. poll()). POSIX
greift also von der Unix-Warte aus gesehen nicht weit genug durch,
aber das muß man akzeptieren, wenn man den Anspruch von POSIX würdigt,
eben nicht nur ein Unix-Standard zu sein, sondern einer, der
prinzipiell auch die Portabilität auf Systeme wie VMS, ... gestatten
soll, die ja zum Teil völlig anders aufgebaut sind.
> Und nun haben wir auch noch Linux mit den Untersekten RH, SuSe,
> Debian & Co.
Die sich aber gerade aus der Sicht eines an POSIX orientierten
Programmierers so gut wie gar nicht unterscheiden, da sie alle
dieselbe C-Bibliothek (modulo Versionsnummer) und dieselben
(größtenteils GNU-basierten) Softwarewerkzeuge benutzen.
> Nur leider keinen technischen Fortschritt mehr.
Auch das kann man nicht so kraß sagen. Es gibt schon technischen
Fortschritt auch auf dem Gebiet der Betriebssysteme (Stichwort:
Sprite, Plan 9, Amoeba, um nur einige Systeme zu nennen, die mit dem
nötigen Support durchaus marktreif (gewesen) wären), nur schaffen die
entsprechenden durchgreifenden Neuerungen es in der Regel nicht in den
Massenmarkt. Das liegt aber hauptsächlich daran, daß der Massenmarkt
offenbar keinen durchgreifenden technischen Fortschritt
wünscht. Bestes Beispiel dafür: Die verschiedenen Windows-Versionen,
die ja seit Jahren nichts Neues bringen, jedenfalls nichts, was so
interessant wäre, daß Microsoft die Welt nicht mit Ziehen und Zerren
dazu bringen müßte, sich endlich die neueste Version zu kaufen (und
selbst das nicht so richtig zu klappen scheint).
Anselm
--
Anselm Lingnau ......................... lin...@tm.informatik.uni-frankfurt.de
Let's get this absolutely straight: no one «needs» Win2K. [...] All we really
know is that Microsoft has decided, as so often in the past, that it is time
again for their "out with the old and in with the new" marketing coup.
-- Rick A. Downes, RISKS Digest 20.82
In Fall Plan 9 gibt es noch Hoffnung, nachdem es jetzt open source ist.
Und BSD- und Linux-seitig kann man ja auch etwas in der Richtung
entwickeln. Z.B. IL-support einbauen. Das kostet wirklich nicht viel.
>wünscht. Bestes Beispiel dafür: Die verschiedenen Windows-Versionen,
>die ja seit Jahren nichts Neues bringen, jedenfalls nichts, was so
>interessant wäre, daß Microsoft die Welt nicht mit Ziehen und Zerren
>dazu bringen müßte, sich endlich die neueste Version zu kaufen (und
>selbst das nicht so richtig zu klappen scheint).
Was M$ betrifft, so ist es ja offensichtlich, daß die echten Fortschritt
absichtlich verweigern. Nicht, weil sie es nicht besser können, sondern weil
es gut für's Geschäft ist. Wenn man die Dinger z.B. diskless booten könnte,
wären sie mir fast -nicht sympathisch- akzeptabel.
Und die neueste Version muß man früher oder später doch einsetzen, weil
ja irgendeine CD-ROM doch nicht mwehr unter 3.11 läuft. Kaufen tut man
sie natürlich nicht. (Wie bei der Bildzeitung)
> Und nun haben wir auch noch Linux mit den Untersekten RH, SuSe,
> Debian & Co. Nur leider keinen technischen Fortschritt mehr.
Genau. Und POSIX, die Linux-Gemeinde und der ganze Rest ist
hundsgemein zu Dir und dem Rest der Welt.
Knapp am Fup2 dag vorbei.
Holger
--
--- http://www.coling.uni-freiburg.de/~schauer/ ---
"Und ja, es ist September im Netz." "Du meinst, es fallen wieder die
Luser vom Baum^W^Waus dem Usenet?" "Nee, eher in's Usenet - und dann
gleich `ein'. Aber es ist ja immer September im Netz."
-- A.Barth und J.Luster in de.alt.sysadmin.recovery
> Z.B. ist "fork" genau wie Symlinks kein Bestandteil von
> POSIX, sondern man findet allenfalls "vfork".
Liebe Leute, bitte informiert euch doch erst einmal über die Fakten,
bevor Ihr über POSIX sprecht.
· Es ist bitter nötig, zwischen verschiedenen POSIX-Standards zu trennen,
hier insbesondere zwischen POSIX.1 und POSIX.2. POSIX.1 behandelt das
»System Application Program Interface (API) [C Language], deckt also
im wesentlichen die klassischen Manpage-Sections 2 und 3 ab. Vom Kern
von POSIX.1 gibt es mehrere Versionen (1988 (hieß nur POSIX), 1990 und
1996), die sich AFAIK nicht sehr unterscheiden; allerdings schließt
die 1996er Version die ehemaligen POSIX.4 bzw. POSIX.1[bci]-Interfaces
als Erweiterungen ein. Die ursprüngliche Frage zur »bash« bezieht
sich hingegen auf POSIX.2, das »Shell and Utilities« und somit etwa
die Manpage-Section 1 behandelt. POSIX.2 ist jünger als POSIX.1 und
längst nicht so umfassend umgesetzt.
· fork() ist selbstverständlich Bestandteil von POSIX.1 (ISO/IEC
9945-1:1996, Abschnitt 3.1.1, S. 57ff). Vfork() hingegen ist aktuell
lediglich Bestandteil von SUSv2.
· ISO/IEC 9945-1:1996, Introduction, S. xiv, Anm. 4, Zeilen 116-118:
# The name POSIX was suggested by Richard Stallman. It is expected
# to be pronounced »pahz-icks«, as in »positive«, not »poh-six«, or
# other variations. The pronunciation has been published in an attempt
# to promulgate a standardized way of referring to a standard operating
# system interface.
Grüße,
Gunnar
> Z.B. ist "fork" genau wie Symlinks kein Bestandteil von
> POSIX, sondern man findet allenfalls "vfork".
Liebe Leute, bitte informiert Euch doch erst einmal über die Fakten,
> POSIX besteht aus mehreren Standards, Part 1 (ISO/IEC 9945-1 -
> ANSI/IEEE Std. 1003.1) hat 784 Seiten und kostet ca. 300 DM und kann
> via DIN online bestellt werden.
Dort bekommt man jedoch nur die Fassung der ISO-WG, die offenbar nicht
immer der gerade aktuellen IEEE-Fassung gleicht.
> Das Problem mit POSIX ist eher, daß viele Sachen, die man für
> »interessante« Programme braucht, eben *nicht* standardisiert
> wurden, da man sich nicht auf eine der beiden Schienen festlegen
> wollte (Stichwort: select() vs. poll()).
Die moralischen Äquivalente zu select() und poll() sind Bestandteil
von POSIX.5.
> Z.B. ist "fork" genau wie Symlinks kein Bestandteil von
> POSIX, sondern man findet allenfalls "vfork".
"fork" ist AFAIK Bestandteil von POSIX.5.
> fork läßt sich unter Systemen wie VMS, MVS oder NT
> kaum implementieren ohne das ganze System umzukrempeln,
> vfork dagegen schon.
Es gibt "fork"-Implementationen für das Win32-Subsystemen von NT,
diese sind aber ähnlich ineffizient wie bei traditionellen
UNIX-Systemen.
Das UNIX-Subsystem von NT hat wohl ein richtiges "fork".
> Der Name stammt angeblich von RMS höchstselbst.
| The following quote appears in the Introduction to POSIX.1: "The
| name POSIX was suggested by Richard Stallman. It is expected to
| be pronounced pahz-icks as in positive, not poh-six, or other
| variations. The pronounciation has been published in an attempt to
| promulgate a standardized way of referring to a standard operating
| system interface".
> Heisst es das die Entwicklung/Anpassung von POSIX nicht mehr
> vorangetrieben wird? Lohnt sich denn so ein Standpunkt als Standard?
Wenn man möglichst viele Hersteller im Boot haben möchte, muß man sich
auf irgendwas einigen.
> Und warum ist dieser nicht frei verfügbar?
Gute Frage. Vermutlich kümmert es keinen. Bei ISO-Normen geht das
Gerücht, daß diese nicht frei verfügbar sein könnten, weil sich sonst
die Normierung nicht finanzieren ließe. Anscheinend war es ein
ziemlicher Kampf, die ISO-Norm für Ada frei verfügbar zu bekommen (was
ein ziemliches Glück ist -- die ISO-Fassung enthält keinen Numerierung
der Absätze ;-). Allerdings hat man sich von Anfang an um dieses
Problem gekümmert (wohl etwa in der Richtung: wir können auch ohne
ISO).
> Damit wird doch nur die Verbreitung erschwert, und viele
> programmieren dann nicht POSIX-konform?
Schlimmer noch: es verhindert die Implementation. Das Schöne an einem
Standard ist, daß man nur noch Code und wenig Dokumentation schreiben
muß. Diesen Vorteil kann man aber als Autor freier Software nicht
nutzen, wenn diese Standards sehr teuer und nicht einmal in
Bibliotheken erhältlich sind.
> BTW: wieviel Aufwendungen (Zeit/Geld) kostet es sich diese Doku zu
> besorgen und welchen Umfang hat sie?
Ein Beispiel: IEEE 1003.5 kostet IIRC 250 Dollar und hat um die
tausend Seiten.
> Schlimmer noch: es [Kosten, Copyright] verhindert die Implementation.
> Das Schöne an einem Standard ist, daß man nur noch Code und wenig
> Dokumentation schreiben muß. Diesen Vorteil kann man aber als Autor
> freier Software nicht nutzen, wenn diese Standards sehr teuer und
> nicht einmal in Bibliotheken erhältlich sind.
Die Beschreibungen der Funktionen in POSIX.1 sind zwar im Prinzip in
Manpage-ähnlicher Form aufgebaut, wären allerdings nur sehr bedingt
als Dokumentation tauglich. Sie sind relativ schwer verständlich, mit
Bemerkungen zur Implementation durchsetzt und zudem voll von »shall«,
»may«, »if ... is defined«, »implementation-defined« &c. IMHO wäre
weder den Autoren von Systemdokumentation noch deren Lesern mit einer
weitreichenden Übernahme besonders gedient.
Davon mal abgesehen ist POSIX.1 die 300-400 DM für die Anschaffung
locker wert. Abgesehen von den eigentlichen Vorschriften bietet vor
allem der Anhang B (informative) »Rationale and Notes« eine Fülle
hochinteressanter Details für den engagierten Systemprogrammierer.
Grüße,
Gunnar
> Lohnt sich denn so ein Standpunkt als Standard? Und warum ist dieser
> nicht frei verfügbar? Damit wird doch nur die Verbreitung erschwert,
> und viele programmieren dann nicht POSIX-konform?
Das mag ein Kulturschock sein, aber Normendokumente sind fast nie
kostenlos erhältlich. Offiziell begründet man das gerne damit, dass
die Entwicklung von Normen und die Infrastruktur einer Normierungs-
organisation bezahlt werden müssen.
Ich vermute, es hat auch etwas mit der Denkweise zu tun. Normen
sind für die Produkte von Firmen vorgesehen, die aus dem Verkauf
dieser Produkte Einnahmen erzielen. Freie Software? Was soll das
sein?
> >fork läßt sich unter Systemen wie VMS, MVS oder NT
> >kaum implementieren ohne das ganze System umzukrempeln,
>
> Darum sind diese auch POSIX-zertifiziert, die meisten Unices aber
> nicht.
Ich war bisher der Meinung, dass alle überlebenden kommerziellen
Unices POSIX-zertifiziert sind. Wieviel Wert auch immer man einer
solchen Zertifizierung beimessen will.
> Das veranlaßt den einen oder anderen "Reverend", be*** Flame-Threads
> in die Welt zu setzen (comp.unix.bsd.freebsd.misc).
Ach, dieser Idiot. Das ist ein Troll. Einfach ins Killfile.
> In der Sache hat Posix das "Problem", nämlich die bekannte Spaltung
> in SysV und BSD, verschlimmbessert, indem eine weitere Sekte
> gegründet wurde.
Unsinn. POSIX hat im Gegenteil gerade das Schisma SysV/BSD überwunden.
Wenn du noch irgendwelche vor-POSIX SysV- oder BSD-Systeme findest,
dann müssen die so 10+ Jahre alt sein.
ftp://ftp.iks-jena.de/pub/mitarb/lutz/standards/ enthält, was ich so frei
gefunden habe. P1003.0 und P1003.6 IIRC ist auch dabei.
> ftp://ftp.iks-jena.de/pub/mitarb/lutz/standards/ enthält, was ich so frei
> gefunden habe. P1003.0 und P1003.6 IIRC ist auch dabei.
Als Drafts. Es ist unverantwortlich, mit Drafts zu arbeiten, wenn
längst die endgültigen Standards erschienen sind. :-/
Stimmt. Saubere Quellen sind mir auch lieber.
> ftp://ftp.iks-jena.de/pub/mitarb/lutz/standards/ enthält, was ich so frei
> gefunden habe. P1003.0 und P1003.6 IIRC ist auch dabei.
standardz.box.sk NOW !!!!11!
Cheers,
Colin
"Christian Weisgerber" <na...@mips.inka.de> schrieb im Newsbeitrag
news:94noti$u6m$1...@kemoauc.mips.inka.de...
In de.comp.os.unix.discussion Mirco <Mir...@web.de> wrote:
^^^^^
Vollstaendiger Realname waere nett...
> Unix Dateisystem Standard (hierarchisches Dateisystem)
> ist Allgemein gültig
Was soll da allgemeingueltig sein (ausser der Existenz von Verzeichnissen)?
Es gibt mehr verschiedene Dateisysteme auf unix-Rechnern als es verschiedene
unix-Systeme gibt (einige aeltere z.T. sogar ohne Softlinks und mit einem
14-Zeichen-Limit fuer Dateinamen, einige mit nicht portablen Erweiterungen
wie acls bei Solaris oder bei ext2 unter linux, einige mit variabler Zahl
von inodes wie reiserfs oder das alte extended Filesystem von linux, ...).
Oder meintest du die Verteilung der Dateien und device-Nodes auf die Ver-
zeichnisse? Wiederum Fehlanzeige. Das beginnt sich bei Linux mittlerweile
etwas anzunaehern, andere unix-Versionen sehen da z.T. komplett anders aus,
noch nicht einmal die Namen der Devices oder gar die ggfs. vorhandene Ver-
zeichnisstruktur unterhalb von /dev sieht bei verschiedenen Systemen unbe-
dingt aehnlich aus. Also wo siehst du ausser der Existenz von Verzeichnissen
wirklich standardisierte Gemeinsamkeiten? Verzeichnisse gibt es bei DOS oder
beim Betriebssystem des Atari ST (moege er seelig ruhen) ebenfalls, aber von
posix (oder aehnlichen Standards) ist das meilenweit entfernt...
> "Christian Weisgerber" <na...@mips.inka.de> schrieb im Newsbeitrag
Und bitte unterlasse in Zukuenftigen Postings das "TOFU" (Text Oben Full-
quote Unten), das gilt im deutschsprachigen USENET eher als schwer ver-
DAUlich...
Tschuess,
Juergen Ilse (il...@asys-h.de)
--
Eingedeutschte Fehlermeldungen sind doch etwas | Juergen Ilse
schoenes: "Gefahr einer Systemverklemmung" | Internet POP Hannover
statt "EDEADLK" in SINIX 1.0B | Vahrenwalder Str. 205
-----------------------------------------------------| 30165 Hannover
Neu in de.comp.os.unix.linux.*? Lies die infos-Gruppe| il...@pop-hannover.net
Aber nicht bei DOS 1.0. Ich glaube ab 2.0 oder 1.2
hat MS die Unterstützung für Festplatten und
Verzeichnisse eingeführt ;)
Version 2.0.
Version 1.0 war gekauft und hieß ursprünglich QDOS für
Quick and Dirty Operation System und war ein CP/M-Clone.
Die DOS-INT 21-Funktionen bis 0x1E oder in der Gegend
sind IMMER NOCH CP/M. (Also ist Windows CP/M, ich wußte
es schon immer.) Kildall von CP/M klaute damals allerdings
die Ideen von einem Minicomputer (frag mich nicht), der
sein System an Unix anlehnte (oder umgekehrt).
Also ist Windows = DOS = Unix.
Der Ideenklau ist immer noch "hipp". Win32 hat nicht von
ungefähr Memory Mapped Files und ein Ereignisprotokoll (syslog).
Florian
> Kildall von CP/M klaute damals allerdings
> die Ideen von einem Minicomputer (frag mich nicht), der
> sein System an Unix anlehnte (oder umgekehrt).
>
> Also ist Windows = DOS = Unix.
CP/M ist nicht von Unix inspiriert (dafür ist es dann doch ein bißchen
primitiv), sondern von DEC-Betriebssystemen der 70er Jahre wie RT-11.
Daher zum Beispiel »\« als Verzeichnistrenner in MS-DOS, da »/« bei
CP/M (und dessen »Inspiration«) als Einleitung für Kommandooptionen
verwendet wurde. Man findet letzteres heutzutage noch bei VMS, wobei
da Verzeichnisse völlig anders aussehen als bei Unix oder DOS/Windows.
Der Hauptgrund für die CP/M-Kompatibilität von QDOS war natürlich, daß
man CP/M-Programme für die 8080-Familie leicht auf dem 8086/88 zum
Laufen bringen können wollte. Die beiden Prozessoren waren auf
Assemblerebene miteinander weitestgehend kompatibel, so daß ein
einfaches Reassemblieren dafür oft reichte.
Anselm
--
Anselm Lingnau ......................... lin...@tm.informatik.uni-frankfurt.de
For the good are always the merry/Save by an evil chance,/And the merry love
the fiddle/And the merry love to dance.
-- William Butler Yeats, *The Fiddler of Dooney*
PUSH AF
PUSH HL
PUSH DE
LD HL,SP
LD DE,8
ADD HL,DE
LD A,M
INC HL
LD H,M
LD L,A
Übertrage das mal auf 8086.
--
Frank Klemm
> Ein Reassemblieren reicht garantiert nicht aus.
> Was wahr ist, daß die meisten 8080-Assemblerbefehle fast identische
> Entsprechungen beim 8086 haben. 8080 in 8085 bzw. Z80 war dagegen
> bis auf 2 Ausnahmen maschinell übertragbar.
Na schön, also Präprozessieren und Reassemblieren (oder Reassemblieren
mit einem geeigneten Makroassembler und passenden Makros?). Am
eigentlichen Inhalt meiner Aussage ändert das natürlich nichts.
Anselm
--
Anselm Lingnau ......................... lin...@tm.informatik.uni-frankfurt.de
Teaching is the process by which the notes of the professor become the notes of
the student without passing through the mind of either. -- Woody Allen
--
Frank Klemm
Wieviele Leute haben eigentlich wirklich 8080-Assembler programmiert?
Wenn Du einmal mit dem guten alten DDT in den Code von CP/M
'reingeschaut hast, dann läuft Dir entweder ein Schauer über den
Rücken, oder Du siehst gleich, daß das meiste in einer Makro-Sprache
geschrieben wurde (ich würde PL/M nicht unbedingt als Hochsprache
bezeichnen).
Ich habe mal in meiner Schulzeit einen Teil von CP/M (genauer: einen
Subset von MP/M) für den Z80 "from scratch" geschrieben, aber in
echtem Assembler. Das war wesentlich kompakter und schneller und
sogar PROM-tauglich.
--
Ciao,
-ha
> Wenn Du einmal mit dem guten alten DDT in den Code von CP/M
> 'reingeschaut hast, dann läuft Dir entweder ein Schauer über den
> Rücken, oder Du siehst gleich, daß das meiste in einer Makro-Sprache
> geschrieben wurde (ich würde PL/M nicht unbedingt als Hochsprache
> bezeichnen).
Naja, das Interessante sind die Applikationen, und von denen waren
tatsächlich viele in »echtem« Assembler geschrieben. Wer's mag ...
Anselm
--
Anselm Lingnau ......................... lin...@tm.informatik.uni-frankfurt.de
I can't understand why people are frightened of new ideas. I'm frightened of
the old ones. -- John Cage
Wenn Du die Zilog-Linie mitzählst, dürften das so wenige gar nicht
gewesen sein. Allein in meinem Bekanntenkreis der 80er mindestens ein
bis zwei Dutzend.
> Ich habe mal in meiner Schulzeit einen Teil von CP/M (genauer: einen
> Subset von MP/M) für den Z80 "from scratch" geschrieben, aber in
> echtem Assembler. Das war wesentlich kompakter und schneller und
> sogar PROM-tauglich.
Mangels brauchbarer Sprachalternativen für den C64 (Ausnahme: Forth)
habe ich auch auf dem 6502 nur Assembler verwendet, wenn was dabei
rauskommen sollte.
Jens
--
Is there anybody listening?
Is there anyone who smiles without a mask?
> Mangels brauchbarer Sprachalternativen für den C64 (Ausnahme: Forth)
> habe ich auch auf dem 6502 nur Assembler verwendet, wenn was dabei
> rauskommen sollte.
Oh ja, das war damals sogar so populär, daß in vielen Zeitschriften
BASIC-Programme für Joe Luser abgedruckt waren, die von PEEK, POKE,
SYS & Co. nur so strotzten...
Aber Assembler war wirklich schnell und speichereffizient; das konnte
man bei handoptimiertem Code noch sehr gut selbst verfolgen. Wie groß
war damals ein "Hello World"?
--
Ciao,
-ha
Ein Hello world hätte auf meiner ersten Kiste so ausgesehen:
DEFW 7F7Fh
DEFM 'HALLO'
DEFB 1
CALL 0F003H
DEFB 23H
DEFM 'Hello World'
DEFB 13,10,0
RET
Der erzeugte Code ist:
7F 7F 48 41 4C 4C 4F 01 CD 03 F0 23 48 65 6C 6C 6f 20 77 6F 72 6C 64 0D 0A
00 C9
--
Frank Klemm
> Mein Bekanntenkreis hat entweder mit dem U880 (Z80 pin-, befehls- und
> bugkompatibel) oder mit dem 6502/6510 angefangen. Ich weiß nicht, ob Du die
> Z80-Leute mit dazuzählst, aber falls ja, so ungefähr 2 Dutzend Leute.
Sorry, ich wollte niemandem zu nahe treten. Ich bezog mich, ohne dies
auszuführen, auf "Applikationen" für CP/M, die z.B. bei CP/M 1.x dabei
waren. Natürlich haben wir in unserer damaligen Computer-AG an der
Schule auch Assembler programmiert. Als wir dann den ersten
Macro-Assembler hatten, fing der Spaß erst richtig an ;)
> Ein Hello world hätte auf meiner ersten Kiste so ausgesehen:
[..]
> CALL 0F003H
[..]
Stringausgabe direkt über das BIOS! Sowas ist natürlich eine
Schweinerei. Wie willst Du das denn umleiten?
--
Ciao,
-ha
Das sollte sich in einem beliebigen Unix auch heute noch in unter 64
Bytes Code unterbringen lassen, wenn man in Assembler programmiert.
Probieren wir es mal unter Linux:
% cat hello3.s
.data
hello:
.string "Hello, world!\n"
.text
.globl _start
_start:
movl $14, %edx
movl $hello, %ecx
movl $1, %ebx
movl $0x4,%eax
int $0x80
xorl %ebx, %ebx
movl $0x1, %eax
int $0x80
% gcc -c hello3.s
% ld -o hello -s hello3.o
% ./hello
Hello, world!
Funktioniert :-)
% ll hello
-rwxr-xr-x 1 hjp hjp 408 Feb 20 20:23 hello*
% size hello
text data bss dec hex filename
31 15 0 46 2e hello
31 Byte Code, 15 Byte Daten. Ist akzeptabel, oder?
hp
--
_ | Peter J. Holzer | All Linux applications run on Solaris,
|_|_) | Sysadmin WSR | which is our implementation of Linux.
| | | h...@wsr.ac.at |
__/ | http://www.hjp.at/ | -- Scott McNealy, Dec. 2000
--
Frank Klemm
Wo kann man sich denn ueber Assembler unter Linux kundig machen? Alles
was ich finde, behandelt DOS und stammt aus max. i386 Zeiten.
- Nikolaus
--
Wenn ich eine SuSE-CD an ein Schwein binde und dieses trete, laufen
KDE & Co. auch ohne RAM recht schnell.
--Robin S. Socha in de.comp.os.unix.linux.newusers--