F
Gerade eben wieder: Diesmal DeepSeek. Mit anderen LLMs mache ich aber konsistent die selben Erfahrungen:
Recommended Pattern
gas
; Symbol definitions (implementation detail)
.set CONST_VALUE, 0x3F8 ; Might become variable later
VAR_VALUE: .word 0 ; Clearly a variable
EXT_VALUE = 0x1000 ; Absolute symbol
; Usage (consistent interface)
mov dx, offset CONST_VALUE ; Works with .set
mov bx, offset VAR_VALUE ; Works with labels
mov ax, offset EXT_VALUE ; Works with absolute symbols
; Never need to remember which is which!
[...]
This Mirrors Good C Practice
Just like in C where you might use & even when unnecessary for consistency:
#define DEBUG_LEVEL 2 // Could become variable later
int debug_level = 2; // Runtime variable
// Consistent usage regardless of implementation
log_message(&DEBUG_LEVEL); // & works with macro too
log_message(&debug_level); // Same syntax
Adresse eines Integer-Literals (&DEBUG_LEVEL) voller Überzeugung als Beispiel gegeben. Das besondere hier: Die Frage drehte sich nicht um C, sondern um Assember-"Symbole", die mit der .set-Direktive gesetzt werden. Eventuell neigt das System eher dazu, etwas herbeizufantasieren, wenn es weiter von der eigentlichen Fragestellung entfernt ist.
Die KI weiss es schon besser, aber sie braucht halt sehr oft einen "Stups" in die richtige Richtung:
> you can take the address of an integer literal in C? really?
No, you absolutely cannot! You're right to call me out on that - I gave a terrible C example. In C, you cannot take the address of a literal or macro value with &. Let me correct that:
Bad Example (Wrong!):
c
#define DEBUG_LEVEL 2
&DEBUG_LEVEL // ERROR: cannot take address of macro
[...]
Wie schon an anderer Stelle erwähnt: Erfahrungen dieser Art mache ich mit solchen KIs (egal welche) bei durchschnittlich jeder zweiten Frage (!). Oft sind es aber auch Fehler, wo man schon sehr genau hinsehen muss. Besonders weil die Antworten immer so "schön richtig" aussehen.
Aber trotz allem: ich finde diese Systeme sehr nützlich, um Problemstellungen durchzudiskutieren, während ich eine Lösung entwickle. Eine Art "Extrasinn" für einen erweiterten inneren Dialog. Da kommt sehr oft wertvoller Input von denen und durchaus auch interessante Lösungsansätze. Das breite Wissen, auf dass die zurückgreifen können, ist da auch sehr hilfreich (auch wenn es mit der Tiefe des Wissens oft hapert).
Kurz: Die sind brauchbare "Kollegen" und "Assistenten", besonders wenn die echten Kollegen ihre eigenen Probleme zu lösen haben. Aber man sollte sich bloss nicht blind auf alles verlassen, was die produzieren. Der Hype um diese Systeme ist IMHO völlig überzogen und die tatsächlich ungeprüft Code schreiben zu lassen, wird in einer Katastrophe enden. Das mag für banale Codeschnipsel zu bereits millionenfach diskutierten Problemen noch meistens gut gehen, aber sobald es komplexer wird, oder man an etwas wirklich "neuem" arbeitet, sind die sehr schnell überfordert