search for: mulhi

...we should be >> using LLVM assembly code and writing part of the bignum library on the >> "other side" of this interface. >> >> If you have time, check out the cminusminus language reference. They >> had a bits1 type for flags, like carry from addition, and a mulhi and >> mullo instruction. Now cminusminus never took off and died an untimely >> death (largely because they wrote it in some bizarre ML in my >> opinion), but from a bignum point of view, they got this one minor >> detail right. > > Hmm... LLVM currently uses i1 prett...

> At -O0, you don't. __mulsi3 is the obvious lowering, and you're doing > something wrong if your tools don't provide it. MSP430 is 16 bit target, so mulsi is a bit expensive there, mulhi / mulqi can be implemented via hardware multiplier. There are several problems wrt 16 bit support inside LLVM in general and msp430 in particular: 1. In some places LLVM expectes 32 bit or 64 bit target (e.g. i32 arguments length argument of memcpy, etc.) 2. On MSP430 the multiplier is an externa...

...y for each machine, we should be > using LLVM assembly code and writing part of the bignum library on the > "other side" of this interface. > > If you have time, check out the cminusminus language reference. They > had a bits1 type for flags, like carry from addition, and a mulhi and > mullo instruction. Now cminusminus never took off and died an untimely > death (largely because they wrote it in some bizarre ML in my > opinion), but from a bignum point of view, they got this one minor > detail right. Hmm... LLVM currently uses i1 pretty extensively, and you ca...

Hi all, After searching for a decent compiler backend for ages (google sometimes isn't helpful), I recently stumbled upon LLVM. Woot!! I work on bignum arithmetic (I'm a professional mathematician) and have recently decided to switch from developing GPL'd bignum code to BSD licensed code. (See http://www.mpir.org/ which I contributed to for a while - a fork of GMP). Please bear with

On Tue, Dec 9, 2008 at 6:11 AM, Zoltan Varga <vargaz at gmail.com> wrote: >> It would be better to implement a target-independent check for >> overflow for the "Legal" case (like how SADDO does). Hacker's > Delight >> has some hints on how to do this. It's not easy for the signed case, >> but is do-able. > > It can be lowered to a division +

On Mon, Oct 8, 2012 at 2:44 AM, Pedro Malagón <malagon at die.upm.es> wrote: > Hi, > > I am trying to complete the hardware multiplier option for MSP430 backend. > > As the hardware multiplier in most of the MSP430 devices is for i8 and > i16 operands, with i16 and i32 result, I am lowering MUL_i8 and MUL_I16. > However, the front-end promotes the i8 argument to i32,

Hi, Here is the next iteration of the patch. The only comment not addressed is this one: > It would be better to implement a target-independent check for > overflow for the "Legal" case (like how SADDO does). Hacker's > Delight > has some hints on how to do this. It's not easy for the signed case, > but is do-able. It can be lowered to a division + a branch,

Hi, I am trying to complete the hardware multiplier option for MSP430 backend. As the hardware multiplier in most of the MSP430 devices is for i8 and i16 operands, with i16 and i32 result, I am lowering MUL_i8 and MUL_I16. However, the front-end promotes the i8 argument to i32, executes 32-bit multiplier and truncates to 16-bit, so I never lower MUL_I8 nor MUL_I16 but MUL_I32, wchich is lowered