-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Incorrect memory allocation for NEW []:INT #29
Comments
Well spotted! |
@Hypexed , can you verify the PPC assembly generates correct code in this case? I've never learned PPC Assembly yet. |
i'm no expert in PPC but i think its broken there also
|
Ok, and W is 32-bit word and H is 16-bit half-word in the store operations. You're right about the fancy rotate 1, mask left 0, mask right 18 to shift. Conclusion: |
Sorry bit late to the party here. From a cursory glance this code generated is slightly poor. Obvious improvements could be made to the code generator. It also knows the numbers ahead of time and yet calculates them on the fly. I don't understand why it sends 2 parameters down the stack twice to FastDispose. So on PPC it also loads in 7 and doubles it. Why it doesn't use 14 directly I have no idea. Also, the PPC uses too many memory stores. On PPC it's standard to use registers for locals but it isn't doing that. Well, I suppose it works. :-) |
The code quality could be addressed by issue #26 . The current code generator is not "production grade" and that issue will allow the replacement of the optimizer and code gen using a recent version of GCC. Please comment there. |
This is probably the cause of issue #8
There needs to be an OPT OPTIMIZE or something similar in EEC/ECX to trigger the register loading optimizations. It's there, you just need to ask for it. |
That's a good idea. For PPC it should be as standard though. The PPC ABI uses registers for function parameters by convention and stores locals in registers as well. It can also call without using stack to optimise calls further. But in this case it lacks a stack frame for debugging. |
When I said "needs to be", I meant either in your code or from the command line. The option is already there. It's shorthand for OPT REGS=MAX + one other optimization. It's equivalent to -O2 in GCC. EditThe command line switch is OPTI to activate optimization. |
Since AllocMem() rounds partial longwords up to the next higher longword length, this can only cause a crash if the deallocation rounds up to a different length than the allocation. Now if I could find where FastNew() is declared, I might be able to find its callsites in the compiler. |
create:
c:=NEW [11,21,31,41,51,61,71]:INT
destroy:
END c[7]
fin:
generates this code:
create:
move.l #$10,d3 (allocate 16 bytes)
move.l d3,-(a7)
bsr.l FastNew
addq.l #4
movea.l d0,a1
move.l #$B,d0
move.w d0,0(a1)
move.l #$15,d1
move.w d1,2(a1)
move.l #$1F,d2
move.w d2,4(a1)
move.l #$29,d0
move.w d0,6(a1)
move.l #$33,d1
move.w d1,8(a1)
move.l #$3D,d2
move.w d2,$A(a1)
move.l #$47,d0
move.w d0,$C(a1)
move.l a1,-4(a5)
destroy:
movea.l -4(a5),a1
moveq #7 (number of elements)
lsl.l #1 (*2 = 14)
move.l d1,-(a7)
move.l a1,-(a7)
move.l a1,d3
move.l d3,-(a7)
move.l d1,-(a7)
bsr.l FastDispose
addq.l #8
movea.l (a7)+,a1
move.l (a7)+,d1
moveq #0,d2
move.l d2,-4(a5)
fin:
so the allocation is 16 bytes but the freeing is only 14 bytes.
The text was updated successfully, but these errors were encountered: