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
Multiplier madness ...................... help
Started by ●September 18, 2008
Reply by ●September 18, 20082008-09-18
Reply by ●September 18, 20082008-09-18
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
> 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
Reply by ●September 18, 20082008-09-18
--- In m..., "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
>
> 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
Reply by ●September 18, 20082008-09-18
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..., "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
>
they have assembler to play with, so much easier, so much more fun, so
much more intuitive!
Al
swarf_maker wrote:
>--- In m..., "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
>
Reply by ●September 18, 20082008-09-18
--- In m..., 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).
>
> 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).
Reply by ●September 19, 20082008-09-19
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'.
> 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'.
Reply by ●September 19, 20082008-09-19
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..., 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..., "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
> >
> >
> >
> >
> >
> >
> >
> >
> >
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..., 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..., "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
> >
> >
> >
> >
> >
> >
> >
> >
> >
Reply by ●September 19, 20082008-09-19
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..., 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..., "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
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
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..., 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..., "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
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
Reply by ●September 19, 20082008-09-19
I guess thats kind of intuitive, if you are at one with the BORG
Al
swarf_maker wrote:
>--- In m..., 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).
>
Al
swarf_maker wrote:
>--- In m..., 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).
>
Reply by ●September 19, 20082008-09-19
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
> 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
