Number Advice

hippy

My background's been in unsigned numbers or using HLL where I've not had to worry about implementation, but for the Propeller Sound Synthesiser I'm working on I've got to deal with signed waves, their multiplication and addition / summation in Assembler and I'm at a bit of a loss on which number representation to use for the waves and virtual pots.

The question is, of the three possibilities I've got ...

Left/-Ve       Mid      +Ve/Right

$00 ---------- $80 ---------- $FF Unsigned         /
                                                  /

$80 ---------- $00 ---------- $7F Two's Comp      /|
                                                   |/

$FF ---------- $00 ---------- $7F One's Comp      \
                                                   |/

Which is the best / easiest to work with for signed multiplication and addition ? I know I'm going to have to do some conversion because things like ADSR ramps and real pots are easiest handled as unsigned but it's trying to get to grips with what should be on 'the analogue path'. I also don't want to have to create multiple maths handling routines.

Any advice or recommendation is appreciated.

Ale

If I tell you I know, I'd lie . In x86 asm, the way was to convert unsigned to signed via (I think is two's complement...): add ah,128 or xor ah,128. (We and our mnemotecnic mind...). As a simple advice, have a look at the mixing routines in mikmod (open source, of course, look for it in freshmeant.net). There is a good implementation there.

Always add, mul and sub... signed, that way you do not lose the sign of the wave.

And post some results, I love electronic music, years of listening to .mod(s)

CardboardGuru

Hi Hippy,

That's not how one's complement goes. It is:
$7F = +127
$0 = +0
$FF = -0
$80 = -127

as opposed to two's complement with is:
$7F = +127
$0 = 0
$80 = -128

To negate a number in one's complement you just do a bitwise NOT.
To negate a number in two's complement you do a bitwise NOT and then add 1.

If you don't have a strange reason for wanting -0, then use two's complement every time. Most signed integer math algorithms use it. The assembler and spin uses it. It makes things easier.

I seem to remember when doing multiply or divide you have to take note of both signs, convert any negatives to positive, do the unsigned operation, then convert the result to negative if necessary. But you have a nice NEG operator in assembler that also works in two's complement.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Help to build the Propeller wiki - propeller.wikispaces.com
Prop Room Robotics - my web store for Roomba spare parts in the UK

Post Edited (CardboardGuru) : 11/21/2007 6:52:24 AM GMT

hippy

Thanks both. You're absolutely right, that's not one's complement. No idea what it would be called. That appealed because it's easier to see a number on a display getting further from zero, but the obvious solution there is to display, not as an 8-digit hex long, but as a signed value. D'oh ! It's true what they say; a little bit of feedback can suddenly kick the neurons into alignment.

Ale : Thanks for the pointer to MikMod, but unfortunately that's GPL'd and I don't wish to propagate any GPL licensing conditions. I've got the code written, just that it's a bit hacked together because my number handling concept drifts all over the place. I've already released some code ( see Spin WAV player thread ) and will release a later version soon. It's coming along nicely, with a good warbling effect churned out with ring modulation - the one maths routine which does work as it's meant to !

Two's complement is undoubtedly the way to go now I've realised that the display issue was just one of perception.

deSilva

When talking of "signed numbers in two's complement representation" you always have to consider the "bit-width" of it. this width can be equal or shorter than the "natural bit-width" you will handle it.

When e.g. having 8 bit signed numbers they run from -128 upto +127, which "looks" in a 16 or 32 bit frameword as if they run from 255 down to 0 upto 127. "Extedning the sign" is a very important operation to improve this embedding.
It is not possible to handle an unsigned number X inside an equal sized signed framework. You have to "split cases" "(X < 0" must be considered as X-MAXP and MAXP handles separately). There is in fact no difference between this and multi-precision arithmetic. Just use your common sense!