Pen^2 (./83) :et ca permet de supprimer des bugs.Mmm ?
[quote]Folco (./85) :
A mon avis c'est pour ça qu'il dit que porter le code vers une compatibilité 64 bits, ça supprime des bugs, parce que ça supprime des hacks qui pèteront sur une archi 64b.
Oui Folco a raison, sur pas mal de code que j'ai vu non compiler en 64bit, ou planter suite a une compilation en 64bit sont du a des bugs de codes ou assomptions qui sont invalide en dehors du monde du 32bit.
Et oui ca permet/force de virer des hacks moches pour pouvoir supporter proprement des archi/bitness different.
En l'occurence VTI n'est pas portable meme vers une autre archi 32bit si on en exclus la GUI
Edit: Ceci dit j'avoue ne pas avoir regardé en détail le code, et je crois qu'on tiens le gagnant en terme de coding style a gerber:
void op_e000(void) /* ASR */
{
ULONG srcreg = imm8_table[((opcode >> 9) & 7)];
ULONG dstreg = opcode & 7;
{{ ULONG cnt = srcreg;
{ BYTE data = regs.d[dstreg].D;
{ UBYTE val = data;
ULONG cmask = 0x80;
ULONG sign = cmask & val;
cnt &= 63;
CLEARFLGS;
if (!cnt) { CFLG = 0; } else {
if (cnt >= 8) {
val = sign ? 0xff : 0;
CFLG=regs.x= sign ? 1 : 0;
} else {
CFLG=regs.x=(val >> (cnt-1)) & 1;
val >>= cnt;
if (sign) val |= 0xff << (8 - cnt);
}}
regs.d[dstreg].B.l = val;
NFLG = sign != 0;
ZFLG = val == 0;
}}}}}
Ca aussi c'est magnifique:
for (i=0;i<0x10000;i++)
garbageMem[i]=0x14;
MC68000_Reset();
regs.pc=initialPC;
contrast=16;
ram128=0;
memprotect=0;
kbmask=0xff;
for (i=0;i<10;i++) kbmatrix[i]=0xff;
ramWrap=0; memAnd=0x3ffff;
onheld=1; lcdBase=0x4c00;
for (i=0;i<6;i++) oldScreenBase[i]=lcdBase;
timer=0; timerInit=0xb2; int0Count=0;
transflag=0; recvflag=0;
transnotready=0;
lcdRefresh=0;L'indentation qui est la juste pour tromper
Et F* maintenant j'ai presque envie de savoir a quel point VTI pourrait etre convertit pour se passer de C++Builder et avoir du code un poil plus propre (et virer ce code ASM stupide)
je reve pas ce truc utilise un version faite main de setjmp/longjmp pour gerere les addresses error o_O
Mais bordel ##facepalm##
