home *** CD-ROM | disk | FTP | other *** search
/ back2roots/padua / padua.7z / padua / text / TagItems / text0002.txt < prev    next >
Encoding:
Text File  |  2014-05-19  |  6.2 KB  |  129 lines
  1. In article <1992Jun30.235526.17184@bernina.ethz.ch>, Markus Wild writes:
  2.  
  3. > Jein... der Effekt ist gleich, nur muss ich im einen Fall ne giganteske
  4. > Library (sprich amiga.lib) dazu linken, die ausserdem noch von Commodore
  5. > mit zweifelhaften `Perlen' ala voellig inkompatibler stdio-Funktionalitaet
  6. > bereicht wuerde, und im andern Fall halt nicht!
  7.  
  8.     Dieses Problem (sofern es eins ist) kann einfach umschifft
  9. werden, indem man sich den Varargs-Stub _selbst_ schreibt. Niemand muss
  10. mit amiga.lib linken, wenn er nicht will.
  11.     
  12. > >ARRAY's anlegen will, der soll's doch bitte _statisch_ tun! Das tut
  13. >
  14. > Noe.. laengst nicht alle Tag-Arrays sind statisch, und wenn Du beginnst,
  15. > statische Arrays dann nachtraeglich doch noch zur Laufzeit zu aendern (und
  16. > das ueblicherweise natuerlich nicht durch Semaphoren schuetzt), dann ist
  17. > die Reentrancy zum Teufel.
  18.  
  19.     Das sollte man natuerlich nicht! Deswegen ja auch der
  20. folgende Absatz! Bitte nicht mehr sinnentstellend quoten! Ich sagte
  21. keineswegs, dass statische Tag-Arrays _immer_ Sinn machen. Es kommt
  22. auf das Wort "solange" (s.u.) an. Fuer solche Faelle hatte ich ausserdem
  23. vorgeschlagen, Varargs und statische Tags zu mischen, falls moeglich.
  24.  
  25. > >einer moeglicherweise gewuenschten Reentrancy solange keinen Abbruch,
  26. > >wie sie 'const' definiert und benutzt werden, was zusaetzlich noch
  27. > >den netten Nebeneffekt hat, dem Compiler eine Optimierungschance
  28. > >mehr einzuraeumen. Und Bezeichnerkonflikten geht man aus dem Weg,
  29. >
  30. > Schon klar, dass const Objekte huebsche Hinweise fuer den Compiler beinhalten,
  31. > nur gibtst Du diesem dadurch, dass Du die Objekte in statischen Speicher
  32. > forcierst (!) keine Chance, sie gaenzlich inline zu expandieren, was ich
  33. > schade finde.
  34.  
  35.     Was ist "schade"? Beschreibe doch mal bitte, was diese
  36. "Inline expansion", was immer damit gemeint sei, in diesem Zusammenhang
  37. an Vorteilen bringt? Ich kann nicht nachvollziehen, inwieweit man die
  38. Zusammenstellung von Daten optimieren kann, die bereits in einer Form
  39. vorliegen, dass man sie 1:1 aus dem Lademodul uebernehmen kann. Unter
  40. der Voraussetzung, dass die verarbeitende Funktion einen _Pointer_ auf
  41. diese Daten erwartet, versteht sich.
  42.  
  43. > >    Ich kann also nicht nachvollziehen, welche tiefere
  44. > >Bedeutung dem Ansinnen zukommt, zur Laufzeit 'automatic' Tagarrays
  45. > >anlegen zu wollen? m.E. bringt das keine zusaetzlichen Vorteile.
  46. >
  47. > Siehe oben. Ausserdem, je mehr Daten Du dem Compiler zur Verfuegung stellst,
  48. > aus denen er versuchen kann, das Optimum rauszuholen, desto besseren Code
  49. > wird er erzeugen.
  50.  
  51.     Redundanzen koennen nie zu mehr als 100% entfernt werden.
  52. Also der gleiche Effekt, als wenn man sie erst gar nicht erzeugt
  53. (was ich versuche, zu propagieren). Darueber den _Compiler_ brueten
  54. zu lassen, erachte ich zumindest als ineffizient (da kommt halt der
  55. Oekonom durch, Informatiker moegen sich an solchen Effekten schon
  56. aus rein wissenschaftlichem Interesse ergoetzen). Es ist zwar schoen,
  57. wenn ein Compiler sowas kann, aber koennte er in dieser Zeit nichts
  58. Sinnvolleres anstellen? Die Rechnung "Mehr Code => Mehr Optimierung"
  59. scheint mir jedenfalls _etwas_ widerspruechlich! :-)
  60.  
  61. > In diesem Fall (jetzt mal von dynamischen Daten aus-
  62. > gehend) hat er entweder die Wahl, zu einem bestimmten Zeitpunkt alle
  63. > Werte zu instantiieren und per Stack an die Varargs Funktion zu uebergeben
  64. > (womit a0/a1/d0/d1 ja wegfallen als Datentraeger), oder sie womoeglich
  65. > ohne Umwege direkt nach erfolgter Berechnung in die spaeter der OS-Funktion
  66. > zu uebergebende Tag-Struktur zu schreiben. Aus diesem Blickwinkel kriegst
  67. > Du mit der Varargs-Version garantiert die schlechteste Loesung, auch wenn
  68. > nicht garantiert ist, dass die andere Variante besser ist.
  69.  
  70.     - a0/a1/d0/d1 fallen frueher oder spaeter _immer_ weg, denn
  71.     wir wollen ja eine Systemfunktion -direkt oder indirekt- aufrufen.
  72.     
  73.     - Die Werte werden auf dem Stack uebergeben, und da _bleiben_
  74.     sie dann auch, weil der Stack damit zum TagArray _wird_.
  75.     
  76.     - 'automatic'-Variablen werden gemeinhin _auch_ nirgendwo
  77.     anders als auf dem Stack instantiiert. Jede Abweichung
  78.     hiervon erzeugt _nochmals_ zusaetzlichen Code zur Speicher-
  79.     beschaffung, Verwaltung und abschliessender Freigabe.
  80.  
  81.     - Die Schlussfolgerung ist in diesem Zusammenhang falsch.
  82.  
  83. > >    Strings initialisiert man in C gemeinhin _immer_ statisch.
  84. > >Zur Laufzeit geht das nur mit strcpy() e.a..
  85. >
  86. > Ooch.. bist Du aber K&R treu.. nur weil das immer so war, muss das doch
  87. > nicht immer so bleiben?!
  88.  
  89.     Was gewinnt man durch die automatic-Deklaration von Strings?
  90. Ein _builtin_strcpy() vom (in diesem Falle dann _doch_ wieder statisch
  91. initialisierten) DATA-Segment auf den Stack? Doppelter Speicherbedarf,
  92. zusaetzlicher Code! (Womit nicht gesagt sein soll, dass es fuer diesen
  93. Mehraufwand niemals eine Rechtfertigung geben mag). Ich bin nur sehr
  94. vorsichtig mit "Segnungen" dieser Art. Wer zeitkritische Applikationen
  95. schreibt, mag hunderte von builtin-Funktionen und damit verbundene
  96. Codegenerierung erdulden [nur am Rande: strcpy() ist m.E. _selten_ der
  97. ideale Ansatzpunkt fuer Optimierungen], ansonsten erzeugen Funktionsaufrufe
  98. aber regelmaessig _kuerzeren_ Code. Keine Frage "K&R vs. ANSI" sondern ganz
  99. einfach "Effizienz vs. Komfort"!
  100.  
  101. > Es ist doch durchaus huebsch, mktemp(3) so
  102. > zu implementieren:
  103. >   char template[] = "ram:t/tmpl.XXXXXX";
  104.  
  105.     "Huebsch" ist eine subjektive Empfindung. Tatsache ist, dass
  106. im fertigen Objektmodul sowohl der initiale Stringinhalt im DATA-
  107. Segment steht, zum Funktionseintritt als erstes von dort auf den
  108. Stack _umkopiert_ wird, um dann gleich wieder in subsequenten
  109. Konstrukten _ueberschrieben_ zu werden. Da bleibt die Effizienz doch
  110. irgendwo auf der Strecke, findest Du nicht? Selbst unter der Annahme,
  111. dass der erste Schritt "wegoptimiert" wird (der Compiler finde irgendwie
  112. (?) heraus, dass der initiale Inhalt von template[] nicht benoetigt werde),
  113. gewinnt man mit dieser Moeglichkeit unterm Strich _nichts_.
  114.     
  115. > [...] Die ANSI-Variante sieht nicht
  116. > nur schoener aus, sondern ist auch einfacher zu verwenden, IMHO ;-)
  117.  
  118.     Die Frage lautet halt immer: "Wieviel Bytes ist Dir
  119. Deine Faulheit wert" :-) :-).
  120.  
  121. > Markus M. Wild    -  wild@nessie.cs.id.ethz.ch  |  wild@amiga.physik.unizh.ch
  122.  
  123. --
  124. Best regards,
  125. Franz-Josef Reichert   GERMANY - VOICE: +49 6805 7417
  126. Kuchlingerstrasse 13   UUCP: fjrei@kbsaar.{saar|adsp}.sub.org
  127. 6601 Kleinblittersdorf        fjrei@kbsaar.saar.de
  128.  
  129.