© 1995-2008 by The FreeBSD Project. All rights reserved.URL: http://www.FreeBSD.de
nornagest 2007-09-06 07:46:36 UTC
FreeBSD German Documentation Repository
Modified files:
books/developers-handbook/x86 chapter.sgml
Log:
Abschnitt 12.8.1 ergaenzt
Revision Changes Path
1.14 +164 -189 de-docproj/books/developers-handbook/x86/chapter.sgml
Index: chapter.sgml
===================================================================
RCS file: /home/cvs/de-docproj/books/developers-handbook/x86/chapter.sgml,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -I$FreeBSDde.*$ -r1.13 -r1.14
--- chapter.sgml 4 Sep 2007 13:24:24 -0000 1.13
+++ chapter.sgml 6 Sep 2007 07:46:36 -0000 1.14
@@ -1215,8 +1215,8 @@
verändert: Wir benutzen Register, wo wir anderenfalls
globale Variablen im Abschnitt <varname>.data</varname>
verwenden müssten. Das ist auch der Grund, warum die
- &unix;-Konvention, Parameter auf dem Stack zu übergeben, der
- von Microsoft, hierfür Register zu verwenden,
+ &unix;-Konvention, Parameter auf dem Stack zu übergeben,
+ der von Microsoft, hierfür Register zu verwenden,
überlegen ist: Wir können Register für unsere
eigenen Zwecke verwenden.</para>
@@ -1240,18 +1240,17 @@
48 65 72 65 20 49 20 63 6F 6D 65 21 0A
<userinput>^D</userinput> &prompt.user;</screen>
+ <para>Nicht was Sie erwartet haben? Das Programm hat die Ausgabe
+ nicht auf dem Bildschirm ausgegeben bis sie
+ <userinput>^D</userinput> gedrückt haben. Das kann man
+ leicht zu beheben indem man drei Zeilen Code einfügt,
+ welche die Ausgabe jedesmal schreiben, wenn wir einen
+ Zeilenumbruch in <constant>0A</constant> umgewandelt haben. Ich
+ habe die betreffenden Zeilen mit > markiert (kopieren Sie die
+ > bitte nicht mit in Ihre
+ <filename>hex.asm</filename>).</para>
-<para>
-Not what you expected? The program did not print the output
-until we pressed <userinput>^D</userinput>. That is easy to fix by
-inserting three lines of code to write the output every time
-we have converted a new line to <constant>0A</constant>. I have marked
-the three lines with > (do not copy the > in your
-<filename>hex.asm</filename>).
-</para>
-
-<programlisting>
-%include 'system.inc'
+ <programlisting>%include 'system.inc'
%define BUFSIZE 2048
@@ -1346,14 +1345,12 @@
add esp, byte 12
sub eax, eax
sub ecx, ecx ; buffer is empty now
- ret
-</programlisting>
+ ret</programlisting>
-<para>
-Now, let us see how it works:
-</para>
+ <para>Lassen Sie uns jetzt einen Blick darauf werfen, wie es
+ funktioniert.</para>
-<screen>&prompt.user; <userinput>nasm -f elf hex.asm</userinput>
+ <screen>&prompt.user; <userinput>nasm -f elf hex.asm</userinput>
&prompt.user; <userinput>ld -s -o hex hex.o</userinput>
&prompt.user; <userinput>./hex</userinput>
<userinput>Hello, World!</userinput>
@@ -1362,179 +1359,157 @@
48 65 72 65 20 49 20 63 6F 6D 65 21 0A
<userinput>^D</userinput> &prompt.user;</screen>
-<para>
-Not bad for a 644-byte executable, is it!
-</para>
-
-<note>
-<para>
-This approach to buffered input/output still
-contains a hidden danger. I will discuss—and
-fix—it later, when I talk about the
-<link linkend="x86-buffered-dark-side">dark
-side of buffering</link>.</para>
-</note>
-
-<sect2 id="x86-ungetc">
-<title>How to Unread a Character</title>
-
-<warning><para>
-This may be a somewhat advanced topic, mostly of interest to
-programmers familiar with the theory of compilers. If you wish,
-you may <link linkend="x86-command-line">skip to the next
-section</link>, and perhaps read this later.
-</para>
-</warning>
-<para>
-While our sample program does not require it, more sophisticated
-filters often need to look ahead. In other words, they may need
-to see what the next character is (or even several characters).
-If the next character is of a certain value, it is part of the
-token currently being processed. Otherwise, it is not.
-</para>
-
-<para>
-For example, you may be parsing the input stream for a textual
-string (e.g., when implementing a language compiler): If a
-character is followed by another character, or perhaps a digit,
-it is part of the token you are processing. If it is followed by
-white space, or some other value, then it is not part of the
-current token.
-</para>
+ <para>Nicht schlecht für eine 644 Byte große
+ Binärdatei, oder?</para>
-<para>
-This presents an interesting problem: How to return the next
-character back to the input stream, so it can be read again
-later?
-</para>
-
-<para>
-One possible solution is to store it in a character variable,
-then set a flag. We can modify <function>getchar</function> to check the flag,
-and if it is set, fetch the byte from that variable instead of the
-input buffer, and reset the flag. But, of course, that slows us
-down.
-</para>
-
-<para>
-The C language has an <function>ungetc()</function> function, just for that
-purpose. Is there a quick way to implement it in our code?
-I would like you to scroll back up and take a look at the
-<function>getchar</function> procedure and see if you can find a nice and
-fast solution before reading the next paragraph. Then come back
-here and see my own solution.
-</para>
-
-<para>
-The key to returning a character back to the stream is in how
-we are getting the characters to start with:
-</para>
-
-<para>
-First we check if the buffer is empty by testing the value
-of <varname role="register">EBX</varname>. If it is zero, we call the
-<function>read</function> procedure.
-</para>
-
-<para>
-If we do have a character available, we use <function role="opcode">lodsb</function>, then
-decrease the value of <varname role="register">EBX</varname>. The <function role="opcode">lodsb</function>
-instruction is effectively identical to:
-</para>
-
-<programlisting>
- mov al, [esi]
- inc esi
-</programlisting>
-
-<para>
-The byte we have fetched remains in the buffer until the next
-time <function>read</function> is called. We do not know when that happens,
-but we do know it will not happen until the next call to
-<function>getchar</function>. Hence, to "return" the last-read byte back
-to the stream, all we have to do is decrease the value of
-<varname role="register">ESI</varname> and increase the value of <varname role="register">EBX</varname>:
-</para>
-
-<programlisting>
-ungetc:
- dec esi
- inc ebx
- ret
-</programlisting>
-
-<para>
-But, be careful! We are perfectly safe doing this if our look-ahead
-is at most one character at a time. If we are examining more than
-one upcoming character and call <function>ungetc</function> several times
-in a row, it will work most of the time, but not all the time
-(and will be tough to debug). Why?
-</para>
-
-<para>
-Because as long as <function>getchar</function> does not have to call
-<function>read</function>, all of the pre-read bytes are still in the buffer,
-and our <function>ungetc</function> works without a glitch. But the moment
-<function>getchar</function> calls <function>read</function>,
-the contents of the buffer change.
-</para>
-
-<para>
-We can always rely on <function>ungetc</function> working properly on the last
-character we have read with <function>getchar</function>, but not on anything
-we have read before that.
-</para>
-
-<para>
-If your program reads more than one byte ahead, you have at least
-two choices:
-</para>
----------------------------------------------
Diff block truncated. (Max lines = 200)
----------------------------------------------
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-cvs-doc" in the body of the message
Received on Thu 06 Sep 2007 - 09:48:12 CEST