Compiler bug in functions >6 parameters

[tomsmart1]

da fällt mir auf die schnelle keine Lösung ein. Problem ist, dass blitzbasic immer die register hochzählt. schriebt man einen Term werden je nach klammer mehrere Register benötigt. Da es nur 8 gibt, gehen bei komplexen termen mit klammern die Register aus. Dass war schon bei blitz der fall, aber fiel da nicht auf, weil man ja nur 6 Parameter hatte.

Ja das verstehe ich, wie geschrieben kommt jetzt damit die neue Fehlermeldung, der Code hat vorher ohne Probleme compiliert und scheint zu funktionieren wird bei AIDE verwendet.

Was mir jetzt nicht ganz klar ist ob diese Problem bei dem Term sich nur auf Funktionsaufrufe oder auf Amiblitz/Blitzbasic generell bezieht auf alle Terme aller x= ........

Der Term benutzt dann für flen(test) register d7. also das letzte. gibt es denn viele solche aufrufe ?.

Es ist mir nur aufgefallen da ich testweise AIDE versucht habe zu kompilieren.

_
Edit: Kommentar Quote richtig gesetzt.

[Berndroesch]

Was mir jetzt nicht ganz klar ist ob diese Problem bei dem Term sich nur auf Funktionsaufrufe oder auf Amiblitz/Blitzbasic generell bezieht auf alle Terme aller x= ........

Die abfrage ist nur bei den Funktionsaufrufen drin, ich habe in amiblitz auch schon vorher ne Meldung formula too complex eingebaut, weil man ja Register Variablen für FPU verwenden kann, die dann für die Formel Berechnung nicht verwendbar sind. Und wenn man zu viele variablen nimmt, dann erzeugen zu komplexe Formeln die Fehlermeldung.

aber ich werde mal genau schauen woran es liegt ist vermutlich nur ne kleinigkeit. interessiert mich auch, wieso da der Compiler ein jsr produziert. Erst dachte ich es wäre ein schlimmer fehler, also dass der compiler die lib adresse nicht findet. aber gestern ist mir dann eingefallen, dass der jsr garnicht rein soll. so muss ich also nur schauen wie der programmablauf ist.

[Berndroesch]

Ich habe das Problem nun gefunden woran es liegt. parnum wurde nicht abgespeichert und auf 0 gesetzt, wenn ein neuer rekursiver Level erreicht wird. (wenn eine Funktion, eine andere Funtkion aufruft). parnum habe ich nun auch nach jedem doppelpunkt : auf 0 gesetzt. somit ist die Parameternummer immer richtig.hier die unterschiede. ist nich viel änderung, das meiste sind kommentare um die stellen besser zu beschreiben

<!-- m --><a class="postlink" href="https://sourceforge.net/p/amiblitz3/code/469/tree//Sourcecodes/Amiblitz3/Compiler/AmiBlitz3.ab3?diff=466">https://sourceforge.net/p/amiblitz3/cod ... 3?diff=466</a><!-- m -->

das exe file habe ich auf amiblitz_test geändert, habe ich vergessen wieder auf beta zu ändern, aber ich finde den namen so besser, denn ein kompiliertes amiblitz compiler sollte nie sich selber überschreiben. wenn das test ok ist, dann kann mans auf beta ändern.

[tomsmart1]

Danke Bernd,

ich habe es getestet und funktioniert. Habe die zwei jetzt unnötigen Fehlermeldungen entfernt und neue Exes erzeugt so das die anderen es auch testen können.

[Der Wanderer]

@Bernd:

Die Distribution sollte deshalb auch AmiBlitz als Exe haben und nicht Beta. Nur das SVN enthält keine non-Beta Executable. Könnte man hinzufügen, wenn das gewünscht ist. Gleiches gilt für PED und könnte man auch mit dem Debugger machen.

Danke für das fixen! Auch die Fehlermeldungen im CLI Mode sind nun sinnvoll. Das motiviert mich AIDE weiter zu entwickeln. Bin gerade dabei mehr Auflösungen zu unterstützen und Type-ahead für Newtypes einzubauen.

[Berndroesch]

findest du die typprüfung nun sinnvoll, was fehlt denn da noch in ab3 ?.

[Der Wanderer]

Die Typenprüfung ist auf jedenfall sehr sehr sinnvoll!

Es gibt noch ein paar Kleinigkeiten:

- die Abfrage schlägt fälschlicherweise fehl, wenn der Wert direkt von einer Funktion kommt und zurückgegeben wird:

[ab3]Syntax 6

NEWTYPE.myType
x.l
End NEWTYPE

Function.myType myFunc1{}
Function Return Null
End Function

Function.myType myFunc2{}
Function Return myFunc1{} ; compiler error
End Function

Function.myType myFunc3{}
*x.myType = myFunc1{}
Function Return *x ; ok
End Function

End[/ab3]

- es findet kein Check bei Primitiven statt, e.g. *rp.RastPort = w.w ist möglich

[Berndroesch]

das mit den funktions schau ich mal an. Ich denke da muss man dann bevor der fehler ausgegeben wird den type der Funktion mit dem type der funktion myfunc1 vergleichen. sieht nicht kompliziert aus, man muss nur in der funktionsliste nach myFunc1 suchen lassen. evtl steht die adresse der func schon irgendwo.

Function Return myFunc1{}

es findet kein Check bei Primitiven statt, e.g. *rp.RastPort = w.w ist möglich

Das hier ergibt aber einen Fehler dass nicht konvertiert werden kann geht also
*x.myType=a.w

der code der das macht steht hier

JL_0_AF98:
EXG.l D2,D3
MOVE.l a0,-(a7)
TRAP #0
TST.b typecheck
BEQ 'ok
TST.b notypecheck
BNE 'ok
MOVE.l leftsidetype,a0
CMP.l #0,leftsidetype
BEQ 'ok
CMP.l #$100,4(a0)
BLE 'ok
CMP.b #3,d3
BEQ 'ok
CMP.b #7,d3
BEQ 'ok
JMP error_convert_types ;for all syntax only long and string allowed to assign to a type
'ok
MOVE.l (a7)+,a0

[Der Wanderer]

Du hast recht.

*rp.RastPort = w.w

ist nicht möglich, aber

*rp.l = w.w
*rp.w = w.w
*rp.b = w.w
*rp.f = w.w