Tim, Earlier you mentioned that you would be interested in seeing how you could help out with the new code on the branch. One thing that would be really great is if we could get the existing assembly code migrated to 32-bit assembly and inlined as asm {} blocks. Currently on the branch (post beta 3) I've added stub routines for the missing assembly code. They are all in the win32 folder. I've removed the #ifdefs that prevented the L_MATH and M_MATH routines from being linked into the code. Stub routines were added with _ASSERTEs that will throw up a dialog box when they are called in the debug build. In release, they will probably have unexpected behavior as I just return 0 all the time for any return value and that's probably not a good thing for all these functions. The stub routines are: mpmath_c.c: MP2d086 MP2d386 MPadd MPadd086 MPadd386 MPcmp MPcmp086 MPcmp386 MPdiv MPdiv086 MPdiv386 MPmul MPmul086 MPmul386 d2MP d2MP086 d2MP386 fg2MP calmanfp.c: calcmandfpasm_287 calcmandfpasm_87 calmanfp5.c: calcmandfpasm_p5 calcmandfpasmstart_p5 parsera.c: Img_Setup fFormula fStkACos fStkACosh fStkAND fStkANDClr2 fStkASin fStkASinh fStkATan fStkATanh fStkAbs fStkAdd fStkCAbs fStkCeil fStkClr1 fStkClr2 fStkCoTan fStkCoTanh fStkConj fStkCos fStkCosXX fStkCosh fStkDbl fStkDiv fStkEQ fStkEndInit fStkExp fStkFlip fStkFloor fStkGT fStkGT2 fStkGTE fStkIdent fStkImag fStkImagFlip fStkJump fStkJumpLabel fStkJumpOnFalse fStkJumpOnTrue fStkLT fStkLT2 fStkLTE fStkLTE2 fStkLod fStkLodAdd fStkLodConj fStkLodDbl fStkLodDup fStkLodEQ fStkLodGT fStkLodGT2 fStkLodGTE fStkLodGTE2 fStkLodImag fStkLodImagAbs fStkLodImagAdd fStkLodImagFlip fStkLodImagMul fStkLodImagSub fStkLodLT fStkLodLT2 fStkLodLTE fStkLodLTE2 fStkLodLTEAnd2 fStkLodLTEMul fStkLodLTMul fStkLodMod2 fStkLodMul fStkLodNE fStkLodReal fStkLodRealAbs fStkLodRealAdd fStkLodRealC fStkLodRealFlip fStkLodRealMul fStkLodRealPwr fStkLodRealSub fStkLodSqr fStkLodSqr2 fStkLodSub fStkLodSubMod fStkLog fStkMod fStkMod2 fStkMul fStkNE fStkNeg fStkOR fStkORClr2 fStkOne fStkPLodAdd fStkPLodSub fStkPull2 fStkPush2 fStkPush2a fStkPush4 fStkPwr fStkReal fStkReal2 fStkRealFlip fStkRecip fStkRound fStkSin fStkSinh fStkSqr fStkSqr0 fStkSqr3 fStkSqrt fStkSto fStkSto2 fStkStoClr1 fStkStoClr2 fStkStoDbl fStkStoDup fStkStoMod2 fStkStoSqr fStkStoSqr0 fStkSub fStkTan fStkTanh fStkTrunc fStkZero fform_per_pixel -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/>
Hi Richard, I'm not sure that adding ASM code is the best way to go. How does this affect the portability of the code across platforms? Can the ASM be replaced with C equivalents? Just an idea. Paul. ---------------------------------------------------------- Paul de Leeuw Computers NSW Central Coast, Australia Email: pdeleeuw@deleeuw.com.au www: < http://www.deleeuw.com.au> ABN 72 360 822 562 ---------------------------------------------------------- -----Original Message----- From: fractdev-bounces+pdeleeuw=deleeuw.com.au@mailman.xmission.com [mailto:fractdev-bounces+pdeleeuw=deleeuw.com.au@mailman.xmission.com] On Behalf Of Richard Sent: Sunday, 28 January 2007 8:40 PM To: fractdev@mailman.xmission.com Subject: [Fractdev] assembly code migration Tim, Earlier you mentioned that you would be interested in seeing how you could help out with the new code on the branch. One thing that would be really great is if we could get the existing assembly code migrated to 32-bit assembly and inlined as asm {} blocks. Currently on the branch (post beta 3) I've added stub routines for the missing assembly code. They are all in the win32 folder. I've removed the #ifdefs that prevented the L_MATH and M_MATH routines from being linked into the code. Stub routines were added with _ASSERTEs that will throw up a dialog box when they are called in the debug build. In release, they will probably have unexpected behavior as I just return 0 all the time for any return value and that's probably not a good thing for all these functions. The stub routines are: mpmath_c.c: MP2d086 MP2d386 MPadd MPadd086 MPadd386 MPcmp MPcmp086 MPcmp386 MPdiv MPdiv086 MPdiv386 MPmul MPmul086 MPmul386 d2MP d2MP086 d2MP386 fg2MP calmanfp.c: calcmandfpasm_287 calcmandfpasm_87 calmanfp5.c: calcmandfpasm_p5 calcmandfpasmstart_p5 parsera.c: Img_Setup fFormula fStkACos fStkACosh fStkAND fStkANDClr2 fStkASin fStkASinh fStkATan fStkATanh fStkAbs fStkAdd fStkCAbs fStkCeil fStkClr1 fStkClr2 fStkCoTan fStkCoTanh fStkConj fStkCos fStkCosXX fStkCosh fStkDbl fStkDiv fStkEQ fStkEndInit fStkExp fStkFlip fStkFloor fStkGT fStkGT2 fStkGTE fStkIdent fStkImag fStkImagFlip fStkJump fStkJumpLabel fStkJumpOnFalse fStkJumpOnTrue fStkLT fStkLT2 fStkLTE fStkLTE2 fStkLod fStkLodAdd fStkLodConj fStkLodDbl fStkLodDup fStkLodEQ fStkLodGT fStkLodGT2 fStkLodGTE fStkLodGTE2 fStkLodImag fStkLodImagAbs fStkLodImagAdd fStkLodImagFlip fStkLodImagMul fStkLodImagSub fStkLodLT fStkLodLT2 fStkLodLTE fStkLodLTE2 fStkLodLTEAnd2 fStkLodLTEMul fStkLodLTMul fStkLodMod2 fStkLodMul fStkLodNE fStkLodReal fStkLodRealAbs fStkLodRealAdd fStkLodRealC fStkLodRealFlip fStkLodRealMul fStkLodRealPwr fStkLodRealSub fStkLodSqr fStkLodSqr2 fStkLodSub fStkLodSubMod fStkLog fStkMod fStkMod2 fStkMul fStkNE fStkNeg fStkOR fStkORClr2 fStkOne fStkPLodAdd fStkPLodSub fStkPull2 fStkPush2 fStkPush2a fStkPush4 fStkPwr fStkReal fStkReal2 fStkRealFlip fStkRecip fStkRound fStkSin fStkSinh fStkSqr fStkSqr0 fStkSqr3 fStkSqrt fStkSto fStkSto2 fStkStoClr1 fStkStoClr2 fStkStoDbl fStkStoDup fStkStoMod2 fStkStoSqr fStkStoSqr0 fStkSub fStkTan fStkTanh fStkTrunc fStkZero fform_per_pixel -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/> _______________________________________________ Fractdev mailing list Fractdev@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/fractdev
In article <000001c742d3$cfeda860$0301a8c0@Production>, "Paul" <pdeleeuw@deleeuw.com.au> writes:
I'm not sure that adding ASM code is the best way to go.
Its the easiest way. Either someone converts the existing assembly to 32-bit or someone converts the existing assembly to C. There is no C code corresponding to these routines; xfractint just didn't port them.
How does this affect the portability of the code across platforms?
Its not portable. But neither is the existing assembly language code.
Can the ASM be replaced with C equivalents?
It can be done, but I don't know assembly well enough to do this, at least not in any reasonable time frame. -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/>
Hi Richard, I guess it depends on what we are trying to achieve. I like the idea of having all the FRACTINT functionality in operating system independent code to link into our own programs like a JPEG library. Much of the ASM code is for high speed integer arithmetic. Do we need it in modern PCs with math coprocessors? The attraction in FRACTINT is the richness of features. The speed is less of an issue now. Just my thoughts anyhow. Thanks, Paul. ---------------------------------------------------------- Paul de Leeuw Computers NSW Central Coast, Australia Email: pdeleeuw@deleeuw.com.au www: < http://www.deleeuw.com.au> ABN 72 360 822 562 ---------------------------------------------------------- -----Original Message----- From: fractdev-bounces+pdeleeuw=telstra.com@mailman.xmission.com [mailto:fractdev-bounces+pdeleeuw=telstra.com@mailman.xmission.com] On Behalf Of Richard Sent: Monday, 29 January 2007 2:53 AM To: Fractint developer's list Subject: Re: [Fractdev] assembly code migration In article <000001c742d3$cfeda860$0301a8c0@Production>, "Paul" <pdeleeuw@deleeuw.com.au> writes:
I'm not sure that adding ASM code is the best way to go.
Its the easiest way. Either someone converts the existing assembly to 32-bit or someone converts the existing assembly to C. There is no C code corresponding to these routines; xfractint just didn't port them.
How does this affect the portability of the code across platforms?
Its not portable. But neither is the existing assembly language code.
Can the ASM be replaced with C equivalents?
It can be done, but I don't know assembly well enough to do this, at least not in any reasonable time frame. -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/> _______________________________________________ Fractdev mailing list Fractdev@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/fractdev
In article <001e01c74314$ac56b900$0301a8c0@Production>, "Paul" <pdeleeuw@deleeuw.com.au> writes:
I guess it depends on what we are trying to achieve. I like the idea of having all the FRACTINT functionality in operating system independent code to link into our own programs like a JPEG library.
I agree, but I'm not an x86 assembly expert and I'm always worried I'm missing some subtlety when transliterating the asm code into C. If someone who is more familiar with the assembly converts it to C, that would be great, but I'd also take a conversion of the asm code to 32-bit. Mostly its just when reading or writing external variables that were declared 'int' -- in the existing assembly these are treated as 2-byte quantities, but the existing code is 4-byte ints, so at the very least the use of the globals has to be changed.
[...] Do we need it in modern PCs with math coprocessors?
Its good to keep it for architectures that have screaming integer performance but not so good floating-point performance, like lots of unix architectures.
The attraction in FRACTINT is the richness of features. The speed is less of an issue now. Just my thoughts anyhow.
The existing fractint code has some features that you don't get unless you get the integer math stuff working. This is some of the stuff that was left out by xfractint that we talked about earlier. Currently this version of FractInt for Windows has more features than xfractint or winfract, if the #ifdefs are any guide. -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/>
participants (2)
-
Paul -
Richard