Prev: Is there a way to implement division by variables other than 2 insingle clock with XST ?
Next: Is there a way to implement division by variables other than 2 in single clock with XST ?
From: glen herrmannsfeldt on 3 Apr 2010 16:16 In comp.arch.fpga MitchAlsup <MitchAlsup(a)aol.com> wrote: (snip) > It was not so much that I was concentratng on Linpack, We (shebanow > and I) were trying to build a machine that could perform as if it were > a vector machine on vectorizable codes (without vector instructions:: > i.e. native 88100 instructions at 6 per cycle) and also perform well > on GCC-like spaghetti codes. Linpack (Matrix 300) was simply the > vector code expample. The 360/91 was also designed to perform well on non-vectorized code. Well, on the code generated for other 360's. Among others is loop mode where for a small enough loop it stops fetching instructions from memory (they are in a special cache). The goal was one instruction per cycle. (With 750ns core it wasn't likely to do more than that.) The 360/91 even had to handle self-modifying code, including instructions that might have already been fetched. The IBM Fortran library for OS/360 did use some self-modifying code. (No recursion in Fortran 66 so it wasn't so hard to do.) -- glen
From: Tim McCaffrey on 5 Apr 2010 14:37
In article <hp87mm$s7m$1(a)naig.caltech.edu>, gah(a)ugcs.caltech.edu says... > >In comp.arch.fpga MitchAlsup <MitchAlsup(a)aol.com> wrote: >(snip) > >> It was not so much that I was concentratng on Linpack, We (shebanow >> and I) were trying to build a machine that could perform as if it were >> a vector machine on vectorizable codes (without vector instructions:: >> i.e. native 88100 instructions at 6 per cycle) and also perform well >> on GCC-like spaghetti codes. Linpack (Matrix 300) was simply the >> vector code expample. > >The 360/91 was also designed to perform well on non-vectorized code. >Well, on the code generated for other 360's. Among others is >loop mode where for a small enough loop it stops fetching >instructions from memory (they are in a special cache). >The goal was one instruction per cycle. (With 750ns core it >wasn't likely to do more than that.) > Must have got that idea from the CDC 6600. >The 360/91 even had to handle self-modifying code, including >instructions that might have already been fetched. The IBM >Fortran library for OS/360 did use some self-modifying code. >(No recursion in Fortran 66 so it wasn't so hard to do.) > SMC was not allowed in the CDC instruction stack (i.e. non-coherent cache). - Tim |