I have started digging into how the multiplies are implemented in my
software.

MSP4301611
IAR 3.42A (should update soon)

I am multiplying two signed integers (16bit signed)

When I look at the assembler listing there is some strange stuff
going on that I just can't figure out ......... my results are off
as well.

signed long ti;
signed int ar, ai;

ti = ai * ar;

Simple enough

ti = ai * ar;
004328 411C 000A mov.w 0xA(SP),R12
00432C 411E 000E mov.w 0xE(SP),R14
004330 12B0 4AF0 call #?Mul16Hw
004334 4C0E mov.w R12,R14
004336 4E0F mov.w R14,R15
004338 E33F inv.w R15
00433A 5F0F rla.w R15
00433C 7F0F subc.w R15,R15
00433E 4E06 mov.w R14,R6
004340 4F07 mov.w R15,R7

?Mul16Hw:
?Mul16to32uHw:
004AE2 1202 push.w SR
004AE4 C232 dint
004AE6 4303 nop
004AE8 4C82 0130 mov.w R12,&MPY
004AEC 4E82 0138 mov.w R14,&OP2
004AF0 421C 013A mov.w &RESLO,R12
004AF4 421D 013C mov.w &RESHI,R13
004AF8 1300 reti
This looks really strange to me.

First it is calling the Mul16to32uHW rather than the signed version.
The high result in R13 is ignored upon return.

R12 is copied to 14, then 14 is copied to 15 then a bunch stuff is
done to 15 and 15 is subracted from itself ........ R14 is placed in
R6 and R15 is placed in R7.

Am I just having a massive brain fart here?

Please bring me back to reality.

What I am really trying to do is the following complex multiplication

tr = ar*RealOut[k] - ai*ImagOut[k];
ti = ar*ImagOut[k] + ai*RealOut[k];

RealOut[] and ImagOut[] are signed longs so the result is computed
using the Mul32Hw macro and takes about 51 cycles for each. I know
the bounds on RealOut[] and was attempting to cast it to a signed int
to use the Mul16to32sHW which is only 29 cycles.

Thanks for your help,
Jeremy

------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

Hi,

> I have started digging into how the multiplies are implemented in my
> software.
>
> MSP4301611
> IAR 3.42A (should update soon)
>
> I am multiplying two signed integers (16bit signed)
>
> When I look at the assembler listing there is some strange stuff
> going on that I just can't figure out ......... my results are off
> as well.

Your understanding is, unfortunately, incorrect.

> signed long ti;
> signed int ar, ai;
>
> ti = ai * ar;
>
> Simple enough

You think that's going to get you the right answer? Think again.

> ti = ai * ar;
> 004328 411C 000A mov.w 0xA(SP),R12
> 00432C 411E 000E mov.w 0xE(SP),R14
> 004330 12B0 4AF0 call #?Mul16Hw
> 004334 4C0E mov.w R12,R14
> 004336 4E0F mov.w R14,R15
> 004338 E33F inv.w R15
> 00433A 5F0F rla.w R15
> 00433C 7F0F subc.w R15,R15
> 00433E 4E06 mov.w R14,R6
> 004340 4F07 mov.w R15,R7
> ?Mul16Hw:
> ?Mul16to32uHw:
> 004AE2 1202 push.w SR
> 004AE4 C232 dint
> 004AE6 4303 nop
> 004AE8 4C82 0130 mov.w R12,&MPY
> 004AEC 4E82 0138 mov.w R14,&OP2
> 004AF0 421C 013A mov.w &RESLO,R12
> 004AF4 421D 013C mov.w &RESHI,R13
> 004AF8 1300 reti
> This looks really strange to me.

Doesn't to me.

> First it is calling the Mul16to32uHW rather than the signed version.

Doesn't need to use a signed version. The multiplication of 16x16->16
yields identical results (bit patterns) for both signed and unsigned
operands. -1x-1 = 1, 0xffff x 0xffff = 1. Doesn't matter a jot, does it?

> The high result in R13 is ignored upon return.

Yep. You're multiplying two ints to generate an int, what did you expect?

> R12 is copied to 14, then 14 is copied to 15 then a bunch stuff is
> done to 15 and 15 is subracted from itself ........ R14 is placed in
> R6 and R15 is placed in R7.

Sign extension.

> Am I just having a massive brain fart here?

I would have to say, "yes".

> Please bring me back to reality.

The above is not enough to jolt you back to reality? Short answer:
understand what your programming language does, not what you think it does.

> What I am really trying to do is the following complex multiplication
>
> tr = ar*RealOut[k] - ai*ImagOut[k];
> ti = ar*ImagOut[k] + ai*RealOut[k];
>
> RealOut[] and ImagOut[] are signed longs so the result is computed
> using the Mul32Hw macro and takes about 51 cycles for each. I know
> the bounds on RealOut[] and was attempting to cast it to a signed int
> to use the Mul16to32sHW which is only 29 cycles.

Does IAR specialise sign-extended 16-bit value x signed 32-bit value? Is
there a 16x32->32 specialisation? I don't think so, not unless you write it
yourself.

Regards,

--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors

------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

Try ti = (long) ai * (long) ar;

Hugh

At 08:28 AM 9/18/2008, you wrote:
I have started digging into how the multiplies are implemented in my
software.

MSP4301611
IAR 3.42A (should update soon)

I am multiplying two signed integers (16bit signed)

When I look at the assembler listing there is some strange stuff
going on that I just can't figure out ......... my results are off
as well.

signed long ti;
signed int ar, ai;

ti = ai * ar;

Simple enough

ti = ai * ar;
004328 411C 000A mov.w 0xA(SP),R12
00432C 411E 000E mov.w 0xE(SP),R14
004330 12B0 4AF0 call #?Mul16Hw
004334 4C0E mov.w R12,R14
004336 4E0F mov.w R14,R15
004338 E33F inv.w R15
00433A 5F0F rla.w R15
00433C 7F0F subc.w R15,R15
00433E 4E06 mov.w R14,R6
004340 4F07 mov.w R15,R7
?Mul16Hw:
?Mul16to32uHw:
004AE2 1202 push.w SR
004AE4 C232 dint
004AE6 4303 nop
004AE8 4C82 0130 mov.w R12,&MPY
004AEC 4E82 0138 mov.w R14,&OP2
004AF0 421C 013A mov.w &RESLO,R12
004AF4 421D 013C mov.w &RESHI,R13
004AF8 1300 reti
This looks really strange to me.

First it is calling the Mul16to32uHW rather than the signed version.
The high result in R13 is ignored upon return.

R12 is copied to 14, then 14 is copied to 15 then a bunch stuff is
done to 15 and 15 is subracted from itself ........ R14 is placed in
R6 and R15 is placed in R7.

Am I just having a massive brain fart here?

Please bring me back to reality.

What I am really trying to do is the following complex multiplication

tr = ar*RealOut[k] - ai*ImagOut[k];
ti = ar*ImagOut[k] + ai*RealOut[k];

RealOut[] and ImagOut[] are signed longs so the result is computed
using the Mul32Hw macro and takes about 51 cycles for each. I know
the bounds on RealOut[] and was attempting to cast it to a signed int
to use the Mul16to32sHW which is only 29 cycles.

Thanks for your help,
Jeremy

------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

Hi Hugh,

> -----Original Message-----
> From: m...@yahoogroups.com [mailto:m...@yahoogroups.com] On Behalf Of
Hugh
> Molesworth
> Sent: 18 September 2008 16:43
> To: m...@yahoogroups.com
> Subject: Re: [msp430] Multiplier madness ...................... help
>
> Try ti = (long) ai * (long) ar;

...I think that's what he's trying to avoid. I believe he requires a
16x32->32 multiply which IAR (and indeed CrossWorks) does not specialize.

--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors

------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

Hi Paul

Good point, I always oversimplify. You must be bored today as well :-)

By the way, I was testing some filesystems, and required a default
size in CrossWorks but didn't see it anywhere so I added it thus:
#define __SIZE_T_TYPE__ unsigned long

I also assume there are no file function headers?

Hugh

At 08:45 AM 9/18/2008, you wrote:
Hi Hugh,

> -----Original Message-----
> From: m...@yahoogroups.com [mailto:m...@yahoogroups.com] On Behalf Of
Hugh
> Molesworth
> Sent: 18 September 2008 16:43
> To: m...@yahoogroups.com
> Subject: Re: [msp430] Multiplier madness ...................... help
>
> Try ti = (long) ai * (long) ar;

....I think that's what he's trying to avoid. I believe he requires a
16x32->32 multiply which IAR (and indeed CrossWorks) does not specialize.

--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors

------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

Hi Hugh,

> Good point, I always oversimplify. You must be bored today as well :-)

I'm not bored! I just implemented a nice new feature in the IDE. :-)

> By the way, I was testing some filesystems, and required a default
> size in CrossWorks but didn't see it anywhere so I added it thus:
> #define __SIZE_T_TYPE__ unsigned long

size_t is actually defined exactly where it should be, in (and
other places, the C standard has hoops you need to jump through). For
MSP430, size_t is in fact just 16 bits wide and is equivalent to plain
'unsigned'.

> I also assume there are no file function headers?

Correct. At present.

--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors

------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

--- In m...@yahoogroups.com, "Paul Curtis" wrote:
>
> Hi,
>
> > I have started digging into how the multiplies are implemented in
my
> > software.
> >
> > MSP4301611
> > IAR 3.42A (should update soon)
> >
> > I am multiplying two signed integers (16bit signed)
> >
> > When I look at the assembler listing there is some strange stuff
> > going on that I just can't figure out ......... my results are
off
> > as well.
>
> Your understanding is, unfortunately, incorrect.
>
> > signed long ti;
> > signed int ar, ai;
> >
> > ti = ai * ar;
> >
> > Simple enough
>
> You think that's going to get you the right answer? Think again.
>
> > ti = ai * ar;
> > 004328 411C 000A mov.w 0xA(SP),R12
> > 00432C 411E 000E mov.w 0xE(SP),R14
> > 004330 12B0 4AF0 call #?Mul16Hw
> > 004334 4C0E mov.w R12,R14
> > 004336 4E0F mov.w R14,R15
> > 004338 E33F inv.w R15
> > 00433A 5F0F rla.w R15
> > 00433C 7F0F subc.w R15,R15
> > 00433E 4E06 mov.w R14,R6
> > 004340 4F07 mov.w R15,R7
> >
> >
> > ?Mul16Hw:
> > ?Mul16to32uHw:
> > 004AE2 1202 push.w SR
> > 004AE4 C232 dint
> > 004AE6 4303 nop
> > 004AE8 4C82 0130 mov.w R12,&MPY
> > 004AEC 4E82 0138 mov.w R14,&OP2
> > 004AF0 421C 013A mov.w &RESLO,R12
> > 004AF4 421D 013C mov.w &RESHI,R13
> > 004AF8 1300 reti
> >
> >
> > This looks really strange to me.
>
> Doesn't to me.
>
> > First it is calling the Mul16to32uHW rather than the signed
version.
>
> Doesn't need to use a signed version. The multiplication of 16x16-
>16
> yields identical results (bit patterns) for both signed and unsigned
> operands. -1x-1 = 1, 0xffff x 0xffff = 1. Doesn't matter a jot,
does it?
>
> > The high result in R13 is ignored upon return.
>
> Yep. You're multiplying two ints to generate an int, what did you
expect?
>
> > R12 is copied to 14, then 14 is copied to 15 then a bunch stuff is
> > done to 15 and 15 is subracted from itself ........ R14 is placed
in
> > R6 and R15 is placed in R7.
>
> Sign extension.
>
> > Am I just having a massive brain fart here?
>
> I would have to say, "yes".
>
> > Please bring me back to reality.
>
> The above is not enough to jolt you back to reality? Short answer:
> understand what your programming language does, not what you think
it does.
>
> > What I am really trying to do is the following complex
multiplication
> >
> > tr = ar*RealOut[k] - ai*ImagOut[k];
> > ti = ar*ImagOut[k] + ai*RealOut[k];
> >
> > RealOut[] and ImagOut[] are signed longs so the result is computed
> > using the Mul32Hw macro and takes about 51 cycles for each. I know
> > the bounds on RealOut[] and was attempting to cast it to a signed
int
> > to use the Mul16to32sHW which is only 29 cycles.
>
> Does IAR specialise sign-extended 16-bit value x signed 32-bit
value? Is
> there a 16x32->32 specialisation? I don't think so, not unless you
write it
> yourself.
>
> Regards,
>
> --
> Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
> CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors
>
Paul,

Thanks for your reply.

I don't think that you have read my posting clearly. I am multiplying
two signed ints and looking for a signed long result. I belive there
is a 16x16 to 32 signed multiplication in IAR as I stated above, it
is called Mul16to32sHW. My problem is that the compiler is calling
the MUl16to32uHW instead. The simple acid test for this is the fact
that I do not get the correct result for the multiplication of two
signed numbers such as -100 x 512. Result should be -51200 not the
14336 that is returned. Becuase the high result is dropped.

In future I would also appreciate it if you could keep your
condecending tone to yourself. The purpose of this forum is to
exchange information, not for assholes like you to slam everyone else.

Jeremy

------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

Hi,

> Paul,
>
> Thanks for your reply.
>
> I don't think that you have read my posting clearly.

Unfortunately, I did. But you haven't understood my answer correctly.

> I am multiplying
> two signed ints and looking for a signed long result.

No MSP430 compiler is going to give you that. None. It just won't happen.

> I belive there
> is a 16x16 to 32 signed multiplication in IAR as I stated above, it
> is called Mul16to32sHW.

Yes. But to get that you need to multiply two longs together.

> My problem is that the compiler is calling
> the MUl16to32uHW instead. The simple acid test for this is the fact
> that I do not get the correct result for the multiplication of two
> signed numbers such as -100 x 512. Result should be -51200 not the
> 14336 that is returned. Becuase the high result is dropped.

Correct. int x int gives an int result. int x int does not give a long
result. Only long x long = long.

-100 = 0xff9c. 512 = 0x200. Two 16-bit ints multiplied gives a result of
0x3800, in decimal 14366. Compiler is correct.

> In future I would also appreciate it if you could keep your
> condecending tone to yourself. The purpose of this forum is to
> exchange information, not for assholes like you to slam everyone else.

Unfortunately, I am not an asshole, but I am blessed with one. I actually
gave you enough information for you to rescue yourself. And Hugh did too.

I will go through it step by step.

int x, y;
long z;
z = x * y;

This multiplies a 16-bit int by a 16-bit int generating a 16-bit int
product. That 16-bit product is then sign-extended to 32 bits. The
compiler is *correct* in its code generation. It doesn't matter whether the
operands are signed or not, doesn't matter a damn, same bit pattern is
generated.

If you *require* a 16x16->32, that is *not* expressible in standard C (with
16-bit ints) as a single operation--you *MUST* go through a long
multiplication which the compiler will then *specialize* by recognizing the
operands have restricted range.

IAR's compiler and my compiler both specialize the following:

int x, y;
long z;
z = (long)x * (long)y;

That will get you a correct result using plain 16-bit multiplication.

My compiler, and I believe IAR's compiler, will *not* specialize the
following, but both *could*:

int x;
long y, z;
z = x * y;

If you can't follow this, all hope is lost.

--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors

------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

Hi,

> In future I would also appreciate it if you could keep your
> condecending tone to yourself. The purpose of this forum is to
> exchange information, not for assholes like you to slam everyone else.

I led you down the path of what you needed to know. I'm a firm believer in
people helping themselves--it's far better for people not to be spoon-fed
the answer, but to work the answer out for themselves. It sticks much
better.

BTW, I'm British, so I actually have an arsehole and fibre keeps it nice and
regular.

--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors

------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

Yeah, I saw that but wanted to avoid altering the existing code. I
changed my definition to leverage of the compiler definition; later
this will go away.
#define __SIZE_T_TYPE__ __SIZE_T

What new feature? I think I'm looking for it ...

At 09:28 AM 9/18/2008, you wrote:
Hi Hugh,

> Good point, I always oversimplify. You must be bored today as well :-)

I'm not bored! I just implemented a nice new feature in the IDE. :-)

> By the way, I was testing some filesystems, and required a default
> size in CrossWorks but didn't see it anywhere so I added it thus:
> #define __SIZE_T_TYPE__ unsigned long

size_t is actually defined exactly where it should be, in (and
other places, the C standard has hoops you need to jump through). For
MSP430, size_t is in fact just 16 bits wide and is equivalent to plain
'unsigned'.

> I also assume there are no file function headers?

Correct. At present.

--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors

------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

Hi Hugh,

> Yeah, I saw that but wanted to avoid altering the existing code. I
> changed my definition to leverage of the compiler definition; later
> this will go away.
> #define __SIZE_T_TYPE__ __SIZE_T
>
> What new feature? I think I'm looking for it ...

You think I'm going to tell you? This conversation may not be secure bud,
you never know who may be eavesdropping.

Stay frosty.

--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors
------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

Hi,

> In future I would also appreciate it if you could keep your
> condecending tone to yourself. The purpose of this forum is to
> exchange information, not for assholes like you to slam everyone else.

This took two minutes to cook on gas mark X:

volatile long z;
int x, y;

z = x * y; // wrong
002118 421C 1100 mov.w &x,R12
00211C 421E 1102 mov.w &y,R14
002120 13B0 2150 calla #?Mul16Hw
002124 4C0D mov.w R12,R13
002126 E33D inv.w R13
002128 5D0D rla.w R13
00212A 7D0D subc.w R13,R13
00212C 4C82 1104 mov.w R12,&z
002130 4D82 1106 mov.w R13,&z+2

z = (long)x * y; // right
002134 421C 1100 mov.w &x,R12
002138 421E 1102 mov.w &y,R14
00213C 13B0 216A calla #?Mul16to32sHw
002140 4C82 1104 mov.w R12,&z
002144 4D82 1106 mov.w R13,&z+2

Comprendez vous?

--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors

------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

--- In m...@yahoogroups.com, "jkw_ee" wrote:
>
> I don't think that you have read my posting clearly. I am
multiplying
> two signed ints and looking for a signed long result. I belive
there
> is a 16x16 to 32 signed multiplication in IAR as I stated above, it
> is called Mul16to32sHW. My problem is that the compiler is calling
> the MUl16to32uHW instead. The simple acid test for this is the fact
> that I do not get the correct result for the multiplication of two
> signed numbers such as -100 x 512. Result should be -51200 not the
> 14336 that is returned. Becuase the high result is dropped.
>
> In future I would also appreciate it if you could keep your
> condecending tone to yourself. The purpose of this forum is to
> exchange information, not for assholes like you to slam everyone
else.
>
> Jeremy
>

There is a better way and it is called Forth.
In Forth, M* does what you want. It takes two signed integers on the
stack and returns a double precision integer on the stack. The
unsigned equivalent is UM* .

-100 512 M* D. -51200 OK

Easy to learn, few rules, extensible, and (IMO best of all)
interactive!

Why the heck does everybody put up with C for embedded applications?

Bob

------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

But then why would anybody work with something as obscure as Forth when
they have assembler to play with, so much easier, so much more fun, so
much more intuitive!

Al

swarf_maker wrote:

>--- In m...@yahoogroups.com, "jkw_ee" wrote:
>
>
>>I don't think that you have read my posting clearly. I am
>>
>>
>multiplying
>
>
>>two signed ints and looking for a signed long result. I belive
>>
>>
>there
>
>
>>is a 16x16 to 32 signed multiplication in IAR as I stated above, it
>>is called Mul16to32sHW. My problem is that the compiler is calling
>>the MUl16to32uHW instead. The simple acid test for this is the fact
>>that I do not get the correct result for the multiplication of two
>>signed numbers such as -100 x 512. Result should be -51200 not the
>>14336 that is returned. Becuase the high result is dropped.
>>
>>In future I would also appreciate it if you could keep your
>>condecending tone to yourself. The purpose of this forum is to
>>exchange information, not for assholes like you to slam everyone
>>
>>
>else.
>
>
>>Jeremy
>>
>>
>>There is a better way and it is called Forth.
>In Forth, M* does what you want. It takes two signed integers on the
>stack and returns a double precision integer on the stack. The
>unsigned equivalent is UM* .
>
> -100 512 M* D. -51200 OK
>
>Easy to learn, few rules, extensible, and (IMO best of all)
>interactive!
>
>Why the heck does everybody put up with C for embedded applications?
>
>Bob
>------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

--- In m...@yahoogroups.com, Onestone wrote:
>
> But then why would anybody work with something as obscure as Forth
when
> they have assembler to play with, so much easier, so much more fun,
so
> much more intuitive!
>
> Al

It is obscure but it shouldn't be.

Forth incorporates an assembler. You can freely mix assembler and
high level code and be much more productive.

Here's the definition of M*:

CODE M* ( n1 n2 -- d )
@S MPYS & MOV
T OP2 & MOV
RESLO & 0 (S) MOV
RESHI & T MOV
RET
END-CODE

Another advantage of Forth (or at least SwiftX - I expect MPE is the
same) is that you get all the source. So if you want/need to know
how M* (for EG) (or any other function works) you just type LOCATE M*
(EG).
------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

swarf_maker wrote:
> There is a better way and it is called Forth.
>

Wow! A blast from the past!

I wrote a Forth compiler, interpreter, that blew 'Capitan Forth' away on
the Apple One. It was that intrinsic characteristic of not being able to
indirect jump on page boundaries. Instead of a double jump involving a
copy address, I let the compiler handle it. My code was fast.

Fast forward, I would not write in anything but C++ if I can help it.
Well, PHP is nice for the web. Now fast is hardly a consideration but at
the abstract level on a box.

Ease of use, I guess Forth is ok at the forklift level. But C is so
natural, and after all, a primitive language. What more could you want???

Best, Dan.
--
email: y...@lakeweb.com but drop the 'x'.
------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

Hello!

There is nothing absolute, nothing working for everyone.
What is intuitive, fun, easy for you might just be unintuitive, boring, obscure, painful
for others.

The discussions like "language A is better than language B because..." are pointless:
everybody comes with his ideas, tries to demonstrate to all the participants
that he's right, and when the discussion finishes, everybody has the same
ideas as before and is possibly upset by a bunch of morons who didn't agree.

I don't know anything about Forth (except what I have read on Wiki), but I am
convinced that the fact that it exists proves that there was a need at some point
or that there is still a need in some specific domain and that its aficionados are
not necessarily obscure.

(you can replace Forth with any language you think of as "obscure").

Pascal

--- In m...@yahoogroups.com, Onestone wrote:
>
> But then why would anybody work with something as obscure as Forth when
> they have assembler to play with, so much easier, so much more fun, so
> much more intuitive!
>
> Al
>
> swarf_maker wrote:
>
> >--- In m...@yahoogroups.com, "jkw_ee" wrote:
> >
> >
> >>I don't think that you have read my posting clearly. I am
> >>
> >>
> >multiplying
> >
> >
> >>two signed ints and looking for a signed long result. I belive
> >>
> >>
> >there
> >
> >
> >>is a 16x16 to 32 signed multiplication in IAR as I stated above, it
> >>is called Mul16to32sHW. My problem is that the compiler is calling
> >>the MUl16to32uHW instead. The simple acid test for this is the fact
> >>that I do not get the correct result for the multiplication of two
> >>signed numbers such as -100 x 512. Result should be -51200 not the
> >>14336 that is returned. Becuase the high result is dropped.
> >>
> >>In future I would also appreciate it if you could keep your
> >>condecending tone to yourself. The purpose of this forum is to
> >>exchange information, not for assholes like you to slam everyone
> >>
> >>
> >else.
> >
> >
> >>Jeremy
> >>
> >>
> >>
> >
> >There is a better way and it is called Forth.
> >In Forth, M* does what you want. It takes two signed integers on the
> >stack and returns a double precision integer on the stack. The
> >unsigned equivalent is UM* .
> >
> > -100 512 M* D. -51200 OK
> >
> >Easy to learn, few rules, extensible, and (IMO best of all)
> >interactive!
> >
> >Why the heck does everybody put up with C for embedded applications?
> >
> >Bob
> >
> >
> >
> >
> >------------------------------------
> >
> >
> >
> >



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

Good grief don't be so serious! From someone who has programmed in most
languages, including FORTH (jupiter Ace and various small hand helds),
on machines ranging from dual main frames through home made RTL based
machines, bit slicers and even Block NORPAK (if anybody has even heard
of that stuff!) to Steve Ciarcia's favourite (he who founded Circuit
cellar), who regularly stated "My favourite programming language is
solder". I just like to stir the shitoccasionally. It's good for the soul.

Al

p_murayama wrote:

>Hello!
>
>There is nothing absolute, nothing working for everyone.
>What is intuitive, fun, easy for you might just be unintuitive, boring, obscure, painful
>for others.
>
>The discussions like "language A is better than language B because..." are pointless:
>everybody comes with his ideas, tries to demonstrate to all the participants
>that he's right, and when the discussion finishes, everybody has the same
>ideas as before and is possibly upset by a bunch of morons who didn't agree.
>
>I don't know anything about Forth (except what I have read on Wiki), but I am
>convinced that the fact that it exists proves that there was a need at some point
>or that there is still a need in some specific domain and that its aficionados are
>not necessarily obscure.
>
>(you can replace Forth with any language you think of as "obscure").
>
>Pascal
>
>--- In m...@yahoogroups.com, Onestone wrote:
>
>
>>But then why would anybody work with something as obscure as Forth when
>>they have assembler to play with, so much easier, so much more fun, so
>>much more intuitive!
>>
>>Al
>>
>>swarf_maker wrote:
>>
>>
>>
>>>--- In m...@yahoogroups.com, "jkw_ee" wrote:
>>>
>>>
>>>
>>>
>>>>I don't think that you have read my posting clearly. I am
>>>>
>>>>
>>>>
>>>>
>>>multiplying
>>>
>>>
>>>
>>>
>>>>two signed ints and looking for a signed long result. I belive
>>>>
>>>>
>>>>
>>>>
>>>there
>>>
>>>
>>>
>>>
>>>>is a 16x16 to 32 signed multiplication in IAR as I stated above, it
>>>>is called Mul16to32sHW. My problem is that the compiler is calling
>>>>the MUl16to32uHW instead. The simple acid test for this is the fact
>>>>that I do not get the correct result for the multiplication of two
>>>>signed numbers such as -100 x 512. Result should be -51200 not the
>>>>14336 that is returned. Becuase the high result is dropped.
>>>>
>>>>In future I would also appreciate it if you could keep your
>>>>condecending tone to yourself. The purpose of this forum is to
>>>>exchange information, not for assholes like you to slam everyone
>>>>
>>>>
>>>>
>>>>
>>>else.
>>>
>>>
>>>
>>>
>>>>Jeremy
>>>>
>>>>
>>>>
>>>>
>>>>
>>>There is a better way and it is called Forth.
>>>In Forth, M* does what you want. It takes two signed integers on the
>>>stack and returns a double precision integer on the stack. The
>>>unsigned equivalent is UM* .
>>>
>>>-100 512 M* D. -51200 OK
>>>
>>>Easy to learn, few rules, extensible, and (IMO best of all)
>>>interactive!
>>>
>>>Why the heck does everybody put up with C for embedded applications?
>>>
>>>Bob
>>>
>>>
>>>
>>>
>>>------------------------------------
>>>
>>>
>>>
>>>



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

I guess thats kind of intuitive, if you are at one with the BORG

Al

swarf_maker wrote:

>--- In m...@yahoogroups.com, Onestone wrote:
>
>
>>But then why would anybody work with something as obscure as Forth
>>
>>
>when
>
>
>>they have assembler to play with, so much easier, so much more fun,
>>
>>
>so
>
>
>>much more intuitive!
>>
>>Al
>>
>>It is obscure but it shouldn't be.
>
>Forth incorporates an assembler. You can freely mix assembler and
>high level code and be much more productive.
>
>Here's the definition of M*:
>
>CODE M* ( n1 n2 -- d )
> @S MPYS & MOV
> T OP2 & MOV
> RESLO & 0 (S) MOV
> RESHI & T MOV
> RET
>END-CODE
>
>Another advantage of Forth (or at least SwiftX - I expect MPE is the
>same) is that you get all the source. So if you want/need to know
>how M* (for EG) (or any other function works) you just type LOCATE M*
>(EG).
>------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

Hi,

> There is nothing absolute, nothing working for everyone.
> What is intuitive, fun, easy for you might just be unintuitive, boring,
> obscure, painful for others.
>
> The discussions like "language A is better than language B because..." are
> pointless:

Well said.

--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors
------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

jkw_ee wrote:
> I have started digging into how the multiplies are implemented in my
> software.
>
> MSP4301611
> IAR 3.42A (should update soon)
>
> I am multiplying two signed integers (16bit signed)

Hi Jkw!

Looks like I'm the last to jump on the band wagon on this one, so I just
try to keep this short.

What you just ran into is the classical "16 bit int" problem In C. The
language standard states that if an operation is applied to two "int":s
the result is also an "int".

In you case you have:

a_long = an_int * another_int;

This is the same thing as:

a_long = (long)(an_int * another_int);

(The assembler instructions doing "RLA" etc. is part of the sign extend
form "int" to "long".)

As a number of people already have pointed out, you need to cast at
least one of the operands to "long" to get a 16*16=>32 multiplication:

a_long = ((long)an_int) * another_int;

Hope this shed some lights on your problem.

-- Anders Lindgren, IAR Systems
--
Disclaimer: Opinions expressed in this posting are strictly my own and
not necessarily those of my employer.

------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

There is a wonderful program that looks through your code and warns you
of little things like this. Its called LINT. It will scour the code
looking for stuff that doesn't match exactly. Kind of a code checker on
steroids. It takes a little time initially, to tame the program and
understand it. Once done, it is highly valuable.

Dan

________________________________

From: m...@yahoogroups.com [mailto:m...@yahoogroups.com] On Behalf
Of Anders Lindgren
Sent: Friday, September 19, 2008 4:56 AM
To: m...@yahoogroups.com
Subject: Re: [msp430] Multiplier madness ...................... help

jkw_ee wrote:
> I have started digging into how the multiplies are implemented in my
> software.
>
> MSP4301611
> IAR 3.42A (should update soon)
>
> I am multiplying two signed integers (16bit signed)

Hi Jkw!

Looks like I'm the last to jump on the band wagon on this one, so I just

try to keep this short.

What you just ran into is the classical "16 bit int" problem In C. The
language standard states that if an operation is applied to two "int":s
the result is also an "int".

In you case you have:

a_long = an_int * another_int;

This is the same thing as:

a_long = (long)(an_int * another_int);

(The assembler instructions doing "RLA" etc. is part of the sign extend
form "int" to "long".)

As a number of people already have pointed out, you need to cast at
least one of the operands to "long" to get a 16*16=>32 multiplication:

a_long = ((long)an_int) * another_int;

Hope this shed some lights on your problem.

-- Anders Lindgren, IAR Systems
--
Disclaimer: Opinions expressed in this posting are strictly my own and
not necessarily those of my employer.

[Non-text portions of this message have been removed]
------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

--- In m...@yahoogroups.com, Dan Bloomquist wrote:
>
> swarf_maker wrote:
> > There is a better way and it is called Forth.
> >
>
> Wow! A blast from the past!

It is still current. You can get cross-tools for the more popular
micros as well as resident Forth for the PC/Win from both Forth Inc.
in the US and MPE in the UK. There are also free versions available
for the PC. Win32Forth is an example.

> I wrote a Forth compiler, interpreter, that blew 'Capitan Forth'
away on
> the Apple One. It was that intrinsic characteristic of not being
able to
> indirect jump on page boundaries. Instead of a double jump
involving a
> copy address, I let the compiler handle it. My code was fast.
>
> Fast forward, I would not write in anything but C++ if I can help
it.
> Well, PHP is nice for the web. Now fast is hardly a consideration
but at
> the abstract level on a box.
>

My preference for Forth is not for its speed but for its
interactivity. I write a (usually) small function and than test it.
Overall, I spend a lot more time testing and a lot less time
debugging than I ever did with C. Also, a lot of the questions asked
here relating to how to make the hardware work could be easily
resolved in an interactive environment with data sheet in hand.

Datasheets are never an easy read and there are clearly many here for
whom English is not their first language. An interactive development
environment might help them too.

> Ease of use, I guess Forth is ok at the forklift level. But C is so
> natural, and after all, a primitive language. What more could you
want???
>

I guess it all depends on what you are comfortable with. I have
written thousands of lines of C/C++ under Windows. I'm not sure I
would undertake a large PC based project in Forth (there are those
who have done so) but for embedded applications, I wouldn't even
consider C where Forth is an option.

I don't get your forklift reference, but as far as C being natural I
would be hard to convinvce on that point. For me, C has too many
rules constraints and subtleties that were always tripping me up. The
recent problem posted by Mike Raines (#38316) is an excellent case in
point.

To reiterate, it all depends on what you are comfortable with. I see
here a lot of people having difficulties with C and with getting
hardware abstraction code working. For them Forth might be a better
alternative. But it appears from this MB that most aren't even aware
of Forth's existence, much less its availability for the MSP430
family.

Bob
> Best, Dan.
> --
> email: yotox@... but drop the 'x'.
>

------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

--- In m...@yahoogroups.com, Onestone wrote:
>
> Good grief don't be so serious! From someone who has programmed in
most
> languages, including FORTH (jupiter Ace and various small hand
helds),
> on machines ranging from dual main frames through home made RTL based
> machines, bit slicers and even Block NORPAK (if anybody has even
heard
> of that stuff!) to Steve Ciarcia's favourite (he who founded Circuit
> cellar), who regularly stated "My favourite programming language is
> solder". I just like to stir the shitoccasionally. It's good for the
soul.
>
> Al

A hardware person at heart, my favorite programming language is also
solder, but at 64 these 0.5 mm lead-pitch parts are a challenge.

NORPAK? The Ottawa company that was pushing Teletext way back when?
------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

----- Original Message -----
From: "swarf_maker"
To:
Sent: Friday, September 19, 2008 3:22 PM
Subject: [msp430] Re: Multiplier madness ...................... help
> --- In m...@yahoogroups.com, Dan Bloomquist wrote:
>>
>> swarf_maker wrote:
>> > There is a better way and it is called Forth.
>> >
>>
>> Wow! A blast from the past!
>
> It is still current. You can get cross-tools for the more popular
> micros as well as resident Forth for the PC/Win from both Forth Inc.
> in the US and MPE in the UK. There are also free versions available
> for the PC. Win32Forth is an example.

Sun used Forth for the I/O drivers on their SPARC systems, perhaps they
still do. It was even possible to boot a Sun machine into a Forth
interpreter. I remember trying it once.

Leon
------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

--- In m...@yahoogroups.com, Onestone wrote:
>
> I guess thats kind of intuitive, if you are at one with the BORG
>
> Al

Intuitive is Pacman. There isn't a manual, you don't need one. There
are no intuitive programming languages. They all require manuals that
sell for $40.00 and up in mafia run university bookstores.

Keep on stirring that stuff.

Bob
------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

Hardware raised, software dedicated. I love my code! The two are like
sausage and mash, or fish and Chips, one is not the same without the other!

Block NORPAK was an old Square D thing. House Brick sized boxes each
with a different logic function. Most had more than 1 gate type per
brick. each gate sat on its own insulated brass strip, and you patch
wired the gates to build circuits. basic unit was NOR gate, hence the
name. There were also OR, delay, potentiometer, single bit memory (ie
latches) that I can remember. weirdly enough used extensively in control
systems around Oil refineries. especially in Cat regen towers. I met
this stuff in the early 80's.

Cheers

Al

swarf_maker wrote:

>--- In m...@yahoogroups.com, Onestone wrote:
>
>
>>Good grief don't be so serious! From someone who has programmed in
>>
>>
>most
>
>
>>languages, including FORTH (jupiter Ace and various small hand
>>
>>
>helds),
>
>
>>on machines ranging from dual main frames through home made RTL based
>>machines, bit slicers and even Block NORPAK (if anybody has even
>>
>>
>heard
>
>
>>of that stuff!) to Steve Ciarcia's favourite (he who founded Circuit
>>cellar), who regularly stated "My favourite programming language is
>>solder". I just like to stir the shitoccasionally. It's good for the
>>
>>
>soul.
>
>
>>Al
>>
>>A hardware person at heart, my favorite programming language is also
>solder, but at 64 these 0.5 mm lead-pitch parts are a challenge.
>
>NORPAK? The Ottawa company that was pushing Teletext way back when?
>------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

I've never paid for a programming manual, although I've known a few
progammers who were called Manuel. University Book stores? Wouldn't
know, I got thrown off Flinders University Grounds for going around
spray painting '??' everywhere I saw the name "FLINDERS UNIVERSITY
CAMP?US?".

Pacman? Intuitive? How so, I mean I thought the idea behind PONG was to
teach HEX. Watching that little blob slide off screen, beep ferociously
and count from 0 to 15 gave me this inate understanding of HEX. Don't
tell me there was more to it than that!! What have I missed out on? Is
there no going back?

Al

swarf_maker wrote:

>--- In m...@yahoogroups.com, Onestone wrote:
>
>
>>I guess thats kind of intuitive, if you are at one with the BORG
>>
>>Al
>>
>>Intuitive is Pacman. There isn't a manual, you don't need one. There
>are no intuitive programming languages. They all require manuals that
>sell for $40.00 and up in mafia run university bookstores.
>
>Keep on stirring that stuff.
>
>Bob
>------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

There may be going back: I just heard this morning of an arcade called
1984. It has many of the old electronic arcade games (Pac Man, Ms. Pac
Man, Asteroids, Space Invaders, etc.) and some pin ball machines. A $5
cover charge gives unlimited playing on all games. The bathrooms are
illuminated with blacklight.

The business claims to be the only one like it.

Emmett Redd Ph.D. mailto:E...@missouristate.edu
Professor (417)836-5221
Department of Physics, Astronomy, and Materials Science
Missouri State University Fax (417)836-6226
901 SOUTH NATIONAL Dept (417)836-5131
SPRINGFIELD, MO 65897 USA

Physicists always practice energy conservation.

> -----Original Message-----
> From: m...@yahoogroups.com [mailto:m...@yahoogroups.com]
> On Behalf Of Onestone
> Sent: Friday, September 19, 2008 10:55 AM
> To: m...@yahoogroups.com
> Subject: Re: [msp430] Re: Multiplier madness
> ...................... help
>
> I've never paid for a programming manual, although I've known a few
> progammers who were called Manuel. University Book stores? Wouldn't
> know, I got thrown off Flinders University Grounds for going around
> spray painting '??' everywhere I saw the name "FLINDERS UNIVERSITY
> CAMP?US?".
>
> Pacman? Intuitive? How so, I mean I thought the idea behind
> PONG was to
> teach HEX. Watching that little blob slide off screen, beep
> ferociously
> and count from 0 to 15 gave me this inate understanding of HEX. Don't
> tell me there was more to it than that!! What have I missed
> out on? Is
> there no going back?
>
> Al
>
> swarf_maker wrote:
>
> >--- In m...@yahoogroups.com, Onestone wrote:
> >
> >
> >>I guess thats kind of intuitive, if you are at one with the BORG
> >>
> >>Al
> >>
> >>
> >
> >Intuitive is Pacman. There isn't a manual, you don't need
> one. There
> >are no intuitive programming languages. They all require
> manuals that
> >sell for $40.00 and up in mafia run university bookstores.
> >
> >Keep on stirring that stuff.
> >
> >Bob
> >
> >
> >------------------------------------
> >
> >
> >
> >



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

A local all you can eat joint called CHARLIES DINER has a games room for
the kids with old Space invaders, Galaga and I think Pacman machines.
Again the old sit donw table top type. They're free to play. But the
only blacklight is when somebody smashes the bulbs. Not nice if you wear
thongs.

Al

Redd, Emmett R wrote:

>There may be going back: I just heard this morning of an arcade called
>1984. It has many of the old electronic arcade games (Pac Man, Ms. Pac
>Man, Asteroids, Space Invaders, etc.) and some pin ball machines. A $5
>cover charge gives unlimited playing on all games. The bathrooms are
>illuminated with blacklight.
>
>The business claims to be the only one like it.
>
>Emmett Redd Ph.D. mailto:E...@missouristate.edu
>Professor (417)836-5221
>Department of Physics, Astronomy, and Materials Science
>Missouri State University Fax (417)836-6226
>901 SOUTH NATIONAL Dept (417)836-5131
>SPRINGFIELD, MO 65897 USA
>
>Physicists always practice energy conservation.
>
>
>>-----Original Message-----
>>From: m...@yahoogroups.com [mailto:m...@yahoogroups.com]
>>On Behalf Of Onestone
>>Sent: Friday, September 19, 2008 10:55 AM
>>To: m...@yahoogroups.com
>>Subject: Re: [msp430] Re: Multiplier madness
>>...................... help
>>
>>I've never paid for a programming manual, although I've known a few
>>progammers who were called Manuel. University Book stores? Wouldn't
>>know, I got thrown off Flinders University Grounds for going around
>>spray painting '??' everywhere I saw the name "FLINDERS UNIVERSITY
>>CAMP?US?".
>>
>>Pacman? Intuitive? How so, I mean I thought the idea behind
>>PONG was to
>>teach HEX. Watching that little blob slide off screen, beep
>>ferociously
>>and count from 0 to 15 gave me this inate understanding of HEX. Don't
>>tell me there was more to it than that!! What have I missed
>>out on? Is
>>there no going back?
>>
>>Al
>>
>>swarf_maker wrote:
>>
>>
>>
>>>--- In m...@yahoogroups.com, Onestone wrote:
>>>
>>>
>>>
>>>
>>>>I guess thats kind of intuitive, if you are at one with the BORG
>>>>
>>>>Al
>>>>
>>>>
>>>>
>>>>
>>>Intuitive is Pacman. There isn't a manual, you don't need
>>>
>>>
>>one. There
>>
>>
>>>are no intuitive programming languages. They all require
>>>
>>>
>>manuals that
>>
>>
>>>sell for $40.00 and up in mafia run university bookstores.
>>>
>>>Keep on stirring that stuff.
>>>
>>>Bob
>>>
>>>
>>>------------------------------------
>>>
>>>
>>>
>>>



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )