On Sep 12, 2:52 am, jason wrote:
> Hi
>
> I've removed all the defines HAVE_HOST_CPU_* , except those left
> behind in the msvc build directory.
> Some sacrifices were made , our system would of handled them , but as
> they were only minor optimizations for very old cpus's (ie 386,486), I
> didn't
Hi
I've removed all the defines HAVE_HOST_CPU_* , except those left
behind in the msvc build directory.
Some sacrifices were made , our system would of handled them , but as
they were only minor optimizations for very old cpus's (ie 386,486), I
didn't bother.
There was only one thing for a modern
On Thursday 18 August 2011 08:09:08 Cactus wrote:
> Yes - I will be delighted to see them go as I was never sure what they did!
>
> Brian
They were mainly used in longlong.h gmp-impl.h and gmp.h to separate out the
arch specific stuff , which we now dont need as we use the universal mpn
selec
True , and thats what I've assumed when removing some other stuff. I've just
tried to compile gcc-2.95.3 on my 32bit system and it fails , so I can't even
test it , I may download an old distro to try it later.
gcc-1.* is known to fail compiling MPIR
On Thursday 18 August 2011 07:56:12 Bill Har
Yes - I will be delighted to see them go as I was never sure what they did!
Brian
--
You received this message because you are subscribed to the Google Groups
"mpir-devel" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/mpir-devel/-/L5TSqLXoEioJ.
To post to t
On the other hand one shouldn't expect any hacks to be necessary for
GCC 2.9.5/6. It might Just Work.
Bill.
On 18 August 2011 07:53, Jason wrote:
> Hi
>
> Some thoughts
>
> The gcc farm only goes back to gcc-4.1 in general
> gcc-3.1 was the first gcc to support x86_64
> Slackware 8.1 released 20
Hi
Some thoughts
The gcc farm only goes back to gcc-4.1 in general
gcc-3.1 was the first gcc to support x86_64
Slackware 8.1 released 2002 had gcc-2.95 but slackware 9.0 released 2003 had
gcc-3.2 , and slackware was(not now) generally behind the curve
gcc-2.96 was a redhat patch to 2.95 , gcc 3.
Many machines only have 2.96. The reason is because of its stability I think.
On 17 August 2011 19:38, Jason wrote:
> On Wednesday 17 August 2011 16:08:37 jason wrote:
>> Hi I've removed the define
>> HAVE_HOST_CPU_FAMILY_x86_64
>> as it was not used anywhere , and I plan to get rid of the other
On Wednesday 17 August 2011 16:08:37 jason wrote:
> Hi I've removed the define
> HAVE_HOST_CPU_FAMILY_x86_64
> as it was not used anywhere , and I plan to get rid of the other
> define HAVE_HOST_CPU_*
>
> There is one case left here
> /build.vc10/cfg.h:# define HAVE_HOST_CPU_FAMILY_x86_64 1
>
>
Hi I've removed the define
HAVE_HOST_CPU_FAMILY_x86_64
as it was not used anywhere , and I plan to get rid of the other
define HAVE_HOST_CPU_*
There is one case left here
/build.vc10/cfg.h:# define HAVE_HOST_CPU_FAMILY_x86_64 1
I assume this can be removed as well
Jason
--
You received this
> There are few cpu's which I think MPIR has not been tested on
>
> mpn/sh see
>
> http://en.wikipedia.org/wiki/SuperH
>
> This architecture has been expanded to 64bit :) , but the only asm
> code MPIR has is sh2 which is used in automotive apps :(
>
> mpn/m68k see
>
> http://en.wikipedia.org
On Tuesday 05 July 2011 17:57:40 Jason wrote:
> On Tuesday 05 July 2011 17:14:41 Cactus wrote:
> > Are you using the AMD code on the Intel Architectures?
> >
> > Brian
>
> Yep
> K8 version on K8,core2,atom,netburst
> K10 version on nehalem,sandybridge,bobcat
>
> and I'll tweek the core2 vers
On Jul 5, 8:11 pm, Cactus wrote:
> Optimisation of assembler code for Windows x64 within prologue and epilogue
> code is pretty heavily constrained by the calling conventions so some of
> your changes between versions don't carry across to Windows.
>
> In particular, unless a frame pointer is decl
Optimisation of assembler code for Windows x64 within prologue and epilogue
code is pretty heavily constrained by the calling conventions so some of
your changes between versions don't carry across to Windows.
In particular, unless a frame pointer is declared, the stack pointer must
remain sta
On Tuesday 05 July 2011 17:14:41 Cactus wrote:
> Are you using the AMD code on the Intel Architectures?
>
> Brian
Yep
K8 version on K8,core2,atom,netburst
K10 version on nehalem,sandybridge,bobcat
and I'll tweek the core2 version to use pop/push rather than the redzone , but
that wont affec
Are you using the AMD code on the Intel Architectures?
Brian
--
You received this message because you are subscribed to the Google Groups
"mpir-devel" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/mpir-devel/-/MYmAwdish1AJ.
To post to this group, send ema
On Tuesday 05 July 2011 12:23:34 jason wrote:
> On Jul 4, 8:48 pm, Jason wrote:
> > On Monday 04 July 2011 20:21:46 Cactus wrote:
> > > Looks good!
> > >
> > > I notice that there is new k8 assembler. Is this going to be repeated
> > > for the Intel architectures?
> >
> > Yep , the current code
On Jul 4, 8:48 pm, Jason wrote:
> On Monday 04 July 2011 20:21:46 Cactus wrote:
>
> > Looks good!
>
> > I notice that there is new k8 assembler. Is this going to be repeated for
> > the Intel architectures?
>
> Yep , the current code is already an improvement on Intel , but I can do
> better eg t
On Monday 04 July 2011 20:04:02 Cactus wrote:
> I was worried about the MSVC command line build but I now realise that this
> does do a FAT build (at least I don't think it does). I have translated
> fat_entry.asm for YASM (an interesting exercise!) but I am not sure it is
> useful since some of t
On Monday 04 July 2011 20:13:15 Cactus wrote:
> Sorry about the bad editing above - it shoulkd read:
>
> I was worried about the MSVC command line build but I now realise that this
> DOESN'T do a FAT build (at least I don't think it does).
>
Yep , it don't
> Brian
--
You received this message
On Monday 04 July 2011 20:21:46 Cactus wrote:
> Looks good!
>
> I notice that there is new k8 assembler. Is this going to be repeated for
> the Intel architectures?
Yep , the current code is already an improvement on Intel , but I can do
better eg the multiple carry handling.
> Is it stable
Looks good!
I notice that there is new k8 assembler. Is this going to be repeated for
the Intel architectures? Is it stable enough to do conversion for Windows?
Brian
--
You received this message because you are subscribed to the Google Groups
"mpir-devel" group.
To view this discu
Sorry about the bad editing above - it shoulkd read:
I was worried about the MSVC command line build but I now realise that this
DOESN'T do a FAT build (at least I don't think it does).
Brian
--
You received this message because you are subscribed to the Google Groups
"mpir-devel" group.
To v
I was worried about the MSVC command line build but I now realise that this
does do a FAT build (at least I don't think it does). I have translated
fat_entry.asm for YASM (an interesting exercise!) but I am not sure it is
useful since some of the symbols it uses are alien to Windows (WIndows
d
On Thursday 30 June 2011 20:06:22 Cactus wrote:
> On Jun 30, 5:17 pm, Jason wrote:
> > On Thursday 30 June 2011 16:28:41 Cactus wrote:
> > > On Jun 30, 4:14 pm, Jason wrote:
> > > > On Thursday 30 June 2011 16:07:37 Cactus wrote:
> > > > > On Jun 30, 3:00 pm, Jason wrote:
> > > > > > On Thursday
On Wednesday 29 June 2011 20:10:50 jason wrote:
> On Jun 19, 11:24 pm, Jason wrote:
> > > 24) New Toom22 code , the new code is smaller if we let the high part
> > >
> > > >= low part which is the opposite of the current code , so it's
> > >
> > > probably easier just to rewrite the whole thing.
On Jun 30, 5:17 pm, Jason wrote:
> On Thursday 30 June 2011 16:28:41 Cactus wrote:
>
>
>
>
>
> > On Jun 30, 4:14 pm, Jason wrote:
> > > On Thursday 30 June 2011 16:07:37 Cactus wrote:
> > > > On Jun 30, 3:00 pm, Jason wrote:
> > > > > On Thursday 30 June 2011 07:59:58 Jason wrote:
> > > > > >
On Jun 9, 1:37 pm, Jason wrote:
> Hi
>
> Now that 2.4 is almost ready to go , here's some ideas for mpir-2.5
>
> 1) Release on 1st September
>
> 2) upgrade internals if needed ie yasm,autotools,gnu config
>
> 3) New x64 assembler code
>
> 4) remove explicit support for old cpus sh,m68k,alpha?
Th
On Thursday 30 June 2011 16:28:41 Cactus wrote:
> On Jun 30, 4:14 pm, Jason wrote:
> > On Thursday 30 June 2011 16:07:37 Cactus wrote:
> > > On Jun 30, 3:00 pm, Jason wrote:
> > > > On Thursday 30 June 2011 07:59:58 Jason wrote:
> > > > > On Thursday 30 June 2011 01:51:41 Bill Hart wrote:
> > > >
On Jun 30, 4:14 pm, Jason wrote:
> On Thursday 30 June 2011 16:07:37 Cactus wrote:
>
>
>
>
>
> > On Jun 30, 3:00 pm, Jason wrote:
> > > On Thursday 30 June 2011 07:59:58 Jason wrote:
> > > > On Thursday 30 June 2011 01:51:41 Bill Hart wrote:
> > > > > On 30 June 2011 01:39, Jason wrote:
> > >
On Thursday 30 June 2011 16:07:37 Cactus wrote:
> On Jun 30, 3:00 pm, Jason wrote:
> > On Thursday 30 June 2011 07:59:58 Jason wrote:
> > > On Thursday 30 June 2011 01:51:41 Bill Hart wrote:
> > > > On 30 June 2011 01:39, Jason wrote:
> > > > > On Thursday 30 June 2011 00:42:07 jason wrote:
> > >
On Jun 30, 3:00 pm, Jason wrote:
> On Thursday 30 June 2011 07:59:58 Jason wrote:
>
>
>
>
>
> > On Thursday 30 June 2011 01:51:41 Bill Hart wrote:
> > > On 30 June 2011 01:39, Jason wrote:
> > > > On Thursday 30 June 2011 00:42:07 jason wrote:
> > > >> > 12) Yasm to assemble all asm files , jus
On Thursday 30 June 2011 07:59:58 Jason wrote:
> On Thursday 30 June 2011 01:51:41 Bill Hart wrote:
> > On 30 June 2011 01:39, Jason wrote:
> > > On Thursday 30 June 2011 00:42:07 jason wrote:
> > >> > 12) Yasm to assemble all asm files , just need to get it to work in
> > >> > a FAT build
> > >>
On Thursday 30 June 2011 01:51:41 Bill Hart wrote:
> On 30 June 2011 01:39, Jason wrote:
> > On Thursday 30 June 2011 00:42:07 jason wrote:
> >> > 12) Yasm to assemble all asm files , just need to get it to work in a
> >> > FAT build
> >>
> >> This only happens in a shared build and appears to be
On 30 June 2011 01:39, Jason wrote:
> On Thursday 30 June 2011 00:42:07 jason wrote:
>> > 12) Yasm to assemble all asm files , just need to get it to work in a FAT
>> > build
>>
>> This only happens in a shared build and appears to be caused by square
>> brackets in the fat_entrys.asm file. I not
On Thursday 30 June 2011 00:42:07 jason wrote:
> > 12) Yasm to assemble all asm files , just need to get it to work in a FAT
> > build
>
> This only happens in a shared build and appears to be caused by square
> brackets in the fat_entrys.asm file. I not sure what the sure brackets
> are for? Anyw
> 12) Yasm to assemble all asm files , just need to get it to work in a FAT
> build
This only happens in a shared build and appears to be caused by square
brackets in the fat_entrys.asm file. I not sure what the sure brackets
are for? Anyway the whole thing should be rewritten with RIP relative
a
On Jun 19, 11:24 pm, Jason wrote:
> > 24) New Toom22 code , the new code is smaller if we let the high part
>
> > >= low part which is the opposite of the current code , so it's
>
> > probably easier just to rewrite the whole thing.
>
> Hi
>
> Here is a outline of the new toom22_n code , there are
Yeah, the issue with the accurate version is it's not what you want to
implement in practice for large sizes. Still thinking...
On 20 June 2011 14:06, Jason wrote:
> Perhaps I misunderstood but I thought there was a accurate floating point FFT
> paper , even if it's bounds were large , even so it
Perhaps I misunderstood but I thought there was a accurate floating point FFT
paper , even if it's bounds were large , even so it could be effective given
the large disparity between floating point and integer arithmetic(mainly carry
handling)
On Monday 20 June 2011 13:57:37 Bill Hart wrote:
>
I'm currently working on a floating point FFT, just for the kicks. The
problem is getting any guarantees out of it with regard to accuracy. I
don't know how to solve that problem yet. I think it is an age old
problem that is not just going to lie down and die.
Bill.
On 20 June 2011 13:19, Jason
On Sunday 19 June 2011 23:54:39 Bill Hart wrote:
> Looks promising.
>
> I've started working on FFT's again. So maybe this MPIR release will
> have some new multiplication speedups at last!
>
> Bill.
>
> On 19 June 2011 23:24, Jason wrote:
> >> 24) New Toom22 code , the new code is smaller if w
On Sunday 19 June 2011 23:54:39 Bill Hart wrote:
> Looks promising.
>
> I've started working on FFT's again. So maybe this MPIR release will
> have some new multiplication speedups at last!
>
I'm hoping to do some division stuff as well , but of course time is the
problem.
> Bill.
>
> On 19
Looks promising.
I've started working on FFT's again. So maybe this MPIR release will
have some new multiplication speedups at last!
Bill.
On 19 June 2011 23:24, Jason wrote:
>>
>> 24) New Toom22 code , the new code is smaller if we let the high part
>>
>> >= low part which is the opposite of t
>
> 24) New Toom22 code , the new code is smaller if we let the high part
>
> >= low part which is the opposite of the current code , so it's
>
> probably easier just to rewrite the whole thing.
Hi
Here is a outline of the new toom22_n code , there are obvious O(1) speedups
to do , but I'll l
On Jun 9, 1:41 pm, Jason wrote:
> On Thursday 09 June 2011 13:37:39 Jason wrote:
>
>
>
> > Hi
>
> > Now that 2.4 is almost ready to go , here's some ideas for mpir-2.5
>
> > 1) Release on 1st September
>
> > 2) upgrade internals if needed ie yasm,autotools,gnu config
>
> > 3) New x64 assembler cod
46 matches
Mail list logo
