AI vs HI
Posted: Thu Dec 12, 2024 5:04 pm
The assembler problems I wanted GPT to solve were not QL-specific. The first task was a simple test: Write a 32bit by 32 bit multiplication routine in mc68k assembler. This it solved reasonably well AFAICS, although I havent actually tested the code. Clearly it was something it had seen before.
The next problem was something I had wasted a lot of time over trying to do myself: First I asked if it knew about Exif. It said it did, so then I asked it to write a general mc68k assembler routine to extract the timestamp from a jpeg (Exif is the industry standard convention for storing this kind of information in JPEGs and some other objects). I specified that the file would be in RAM pointed to by a1, and I wanted the result string to be placed in a buffer pointed to by a2. The problem was posed this way so as not to involve any QL-specific stuff. I intended to refine the problem definition depending on the result, and provide the QL interfacing myself.
The outcome was, as already indicated, pretty much nonsense. Thats as far as I got. Until today.
Just now I had another round with GPT trying to get the datestamp. I'll say this for it: It does learn. After a few rounds I got it to understand that 1) cmpm was not a legal instruction; cmp is, and neither is dbxx.s, 2) that my assembler complains of a bxx if a branch instruction could be short. It fixed that, but is clearly not able to calculate correctly as I still had to weed out a few bxxes. 3) It quickly learnt that addq and subq could only work with values of 0 to 8 (and not addq.l #10,d0 as it tried to do) and that moveq only works with byte sized values, which are then sign extended to a long word. 4) I had to tell it that my assembler doesnt accept spaces between arguments, eg move.l d1, d0 should be move.l d1,d0.
I dont know how long it will retain that learning. Perhaps other assemblers are ok with many of the "faults" I found and that Ive now polluted its "mind". It didnt remember me from our last session in February, so perhaps Ill have to do all these corrections again next time..
The end result, after a few hours so far, is code that compiles alright, and looks "normal", although not very efficient. But it also doesnt do the trick! I still cant get the timestamp, although I know its there! It has offered me a version that includes some debugging code. I'll try that some other time as Ive had enough for today.
The next problem was something I had wasted a lot of time over trying to do myself: First I asked if it knew about Exif. It said it did, so then I asked it to write a general mc68k assembler routine to extract the timestamp from a jpeg (Exif is the industry standard convention for storing this kind of information in JPEGs and some other objects). I specified that the file would be in RAM pointed to by a1, and I wanted the result string to be placed in a buffer pointed to by a2. The problem was posed this way so as not to involve any QL-specific stuff. I intended to refine the problem definition depending on the result, and provide the QL interfacing myself.
The outcome was, as already indicated, pretty much nonsense. Thats as far as I got. Until today.
Just now I had another round with GPT trying to get the datestamp. I'll say this for it: It does learn. After a few rounds I got it to understand that 1) cmpm was not a legal instruction; cmp is, and neither is dbxx.s, 2) that my assembler complains of a bxx if a branch instruction could be short. It fixed that, but is clearly not able to calculate correctly as I still had to weed out a few bxxes. 3) It quickly learnt that addq and subq could only work with values of 0 to 8 (and not addq.l #10,d0 as it tried to do) and that moveq only works with byte sized values, which are then sign extended to a long word. 4) I had to tell it that my assembler doesnt accept spaces between arguments, eg move.l d1, d0 should be move.l d1,d0.
I dont know how long it will retain that learning. Perhaps other assemblers are ok with many of the "faults" I found and that Ive now polluted its "mind". It didnt remember me from our last session in February, so perhaps Ill have to do all these corrections again next time..
The end result, after a few hours so far, is code that compiles alright, and looks "normal", although not very efficient. But it also doesnt do the trick! I still cant get the timestamp, although I know its there! It has offered me a version that includes some debugging code. I'll try that some other time as Ive had enough for today.