From: duening@ibr.cs.tu-bs.de (Lars Duening)
Subject: Re: SAS/C Compiler, Stacksize errechnen
Reply-To: duening@ibr.cs.tu-bs.de (Lars Duening)
Organization: TU Braunschweig, Informatik (Bueltenweg), Germany
Date: Mon, 25 Jan 1993 11:48:17 GMT

In <bUCks*s40@oberon.nbg.sub.org> schreibt Hartmut Goebel:

> In article <1993Jan18.152440.29470@ibr.cs.tu-bs.de>, Lars Duening writes:
> 
>  [es geht immer noch darum, ob man Pointer einfach incrementieren kann]
> 
>> Mag sein, dass es im Sinne des Spracherfinders 'unsauber' ist, aber ab
>> und zu lassen sich solche Konstrukte entweder gar nicht vermeiden,
>> oder bieten Effizienzvorteile. Und dann sag ich dem Compiler lieber
> 
> Mir sind eigentlich keine Faelle bewusst, in denen solche Konstruke
> wirklich unvermeidlich waeren. Und die Effizienzsteigerung ist ein zu
> schwaches Argument: besser ein korrektes Programmes als
> eines, das nur auf Effizens getrimm ist und vor Fehlern (gefundene
> und nicht gefundene) strotzt.

Und was ist mit korrekten Programmen, die dennoch auf Effizienz
getrimmt sind?

>> "Dieses Programm sieht zwar unsauber aus, ist aber wirklich so
>> gemeint."
>
> Um das einem Modula-2 oder Oberon[-2] Compiler zu sagen, musst Du hat
> etwas Aufwand treiben. Schliesslich soll es einfacher sein, saubere
> Programme zu schreiben, als Hacks.

Es ist nur deshalb ein Hack (und von daher _wirklich_ und zwangsweise
systemabhaengig), weil es die Sprache nicht definiert.

>> addressierten als naechstes ueber diesen Zeiger erreichen (da mein
>> Oberon-2 noch nicht komplett ist, konnte ich die 'Zeiger auf offene
> 
> ??? soll das einer verstehen?
> Schreibst Du einen eigenen Compiler, oder was, oder wie?

Soll ich? *schelmisch grins*

> AmigaOberon 3.0 unterstaetzt das jedenfalls.

Sorry, es war wirklich missverstaendlich: Ich wollte nur ausdruecken,
dass ich immer noch auf eine lesbare Disk-2 des neuen Amiga-Oberon 3
warte.

>> der Definition der Rechenoperatoren. 'string + string' ist auch kein
>> arithmetischer Ausdruck, aber dennoch sinnvoll.
> 
> INC(prt) ist aber ein arithmetischre Ausdruck, das ist der
> Unterschied. 

Dann ist er halt arithmetisch - je nach Argument Zahlarithmetisch oder
Pointerarithmetisch.

> Oder wasrum denkst Du wohl, ist INC(char) nicht moeglich?

NICHT??? Nur gut, dass ich's bisher nicht brauchte.

>> Wieso? Der GC kann sich ja auf die beschraenken, mit denen ich nicht
>> rechne (Amiga-Oberon 3 hat ja extra die UNTRACED POINTER eingefuehrt,
>> da nicht alles vom GC ueberwacht werden kann).
> 
> Wobei die UNTRACED POINTERS eine eiweiterung von AO sind, die nur
> mit der norwendigkeit begruendet ist, dass halt nicht alle Objekte von
> Oberon erzeugt werden (z.B. Fenster). Ansonsten ist UNTRACED _nicht_
> standard. 

Hab ich auch nicht behauptet :-)

> (Wenn Du jattz anfangen willst, ueber Oberon Standard oder
> nicht zu diskutieren, dann wende Dich erstmal an
> G_DOTZEL@ame.zer.sub.org -- Nein, das sollte keine Flame sein!)

Schon klar. Aber keine Sorge, den Standard wollte ich eigentlich nicht
diskutieren.

>> Eine Option a la (* $Sloppy+ *) waere ja schon ausreichend.
> 
> Und was soll die machen? 

Sie koennte Warnungen/Fehlermeldungen a la 'possibly non-portable
pointer expression' abschalten.

> Und wie willst Du solche Programme dann auf anderen Rechenern kompilieren?

Genauso, wie ich Programme, die SYSTEM verwenden, kompiliere.
In der Regel also gar nicht.

>> Ich finde es halt nur nicht gut, dass vor lauter
>> Highlevel-OOP-Abgehobenheit die Lowlevel-Programmierung unnoetig
>> schwer gemacht wird (und umgekehrt).

Dabei habe ich noch nicht mal den fehlenden Inline-Assembler
angemeckert ;-), na, das neue Binaer-Include tut's auch.

> Es wird nicht schwer gemacht. Schau in das Buch "Project Oberon",
> dort wird das ganz Oberon-System entwickelt und erklaert. Das, was Du
> low-level nennst, findet man dort nicht (oder nut kaum, ich hab das
> Buch nicht auswednig gelernt :-)

Nur dass halt der Amiga eben nicht von Grund auf in Oberon
programmiert wurde. Von daher ist ein bisschen low_level nicht ganz
unnoetig, will man Oberon als alleinige Sprache verwenden.

  Lars
--
Lars Duening; duening@ibr.cs.tu-bs.de