Hi, thanks for looking into this. I do not know if and where print_sword_fp_dec() is used. And, it is not included in format.jal. This procedure uses a kind of weird data format, it prints "<sbyte>.<sbyte>" The largest printable number is 127.99, and it can have a negative fraction, so it can print something like 12.-111
format.jal uses a much more common and imo more sensible format, it does print something like "<sword>/100". The largest number is then 327.67, and those fix-point numbers can be used with normal math operators, the print_sword_fp_dec()-format can not. I do not know why this format is used at all, maybe some hardware uses it. But, in that case, I think it is better to have a conversion routine to calculate a usual fix-point number from that fromat in the concerning hardware-related lib. Greets, Kiste --- mattschinkel <[email protected]> schrieb am Sa, 5.11.2011: > Von: mattschinkel <[email protected]> > Betreff: [jallib] Re: Advertising print_scalable > An: "jallib" <[email protected]> > Datum: Samstag, 5. November, 2011 03:03 Uhr > I see that print_sword_fp_dec() was > removed. Is this procedure used at > all in any samples? I did define it in the debug library, > but I think > I should remove it. > > Maybe it should be removed from print.jal since it is in > format.jal? > > Matt. > > On Oct 30, 9:42 pm, mattschinkel <[email protected]> > wrote: > > Good work, I'll play around with it when I get a > chance. > > > > I don't see any need for 2 separate libs. If this one > is faster and > > indeed scalable, it should replace the existing. > > > > Matt. > > > > On Oct 30, 12:22 pm, Oliver Seitz <[email protected]> > wrote: > > > > > > > > > Don't read if you're in a hurry. > > > Nothing important in this mail, only a whole lot > of waffle. > > > ;-) > > > > > Here are some results of some calculations and > some > > > experiments... > > > > > Memory: > > > > > Both data and code size can be a bit larger or > smaller when > > > you switch from print.jal to print_scalable.jal. > Difference > > > is usually small. It mainly depends, if dword > divisions are > > > used within the program. If you do not need > dwords and limit > > > the range to one or two bytes before including > > > print_scalable.jal, you most certainly will save > ram and > > > flash. > > > > > Speed: > > > > > How long should a conversion from a binary number > to a > > > decimal number take? Simple answer: Not too long. > What is > > > too long? Let's take the fastest PIC and the > slowest > > > interface. > > > > > The slowest and most common interface would be > RS232. It > > > can usually do up to 115200 bit per second. > Counting start- > > > and stopbits, that's 11520 chars per second. > > > > > The decimal representation of a dword has about > 9.74 digits > > > in average. I'll only talk about average values > here. > > > Divided the chars per second by this number gives > 1182.6, > > > which is the number of dwords that can be > transmitted via > > > RS232 per second. > > > > > Lets take a real fast PIC. 64MHz seems > appropriate, that is > > > 16MHz instruction clock. This, divided by the > numbers per > > > second makes 13530 cycles. If a conversion > routine takes > > > less cycles, the interface will set the speed. If > it takes > > > more, the interface will be waiting for the > converted data. > > > If you're thinking at either slower clock speeds, > or at USB, > > > I2C or SPI, the conversion should preferably be > much > > > faster. > > > > > How fast is it, then? For print.jal, I can not > tell yet. > > > The test program is still running. The result so > far is > > > 42906 cycles per dword. This only counts the > numbers 0 to > > > 766158238. That is how far the program made it > after 38 > > > days. > > > > > For print_scalable, I could do some > simplification to get > > > the result faster, so here I got the average for > all the > > > values from 0 to 4294967290 as 3840. That is more > than ten > > > times faster, and, the slowest number > (3999999999) for > > > scalable ist still faster than the so far fastest > number for > > > "conventional" (200000000). (The really fastest > number, > > > zero, is handled by an unfair exception ;-) ) > > > > > Some more examples: at 20MHz, print yields 1135 > chars per > > > second, at 4MHz 227. Print_scalable at 20MHz > converts 12628 > > > chars per second, and 2536 at 4MHz. A 4MHz > controller using > > > print.jal thus can only transmit decimal data at > a rate like > > > 2400 baud, which is not what I would expect. > Print_scalable > > > makes at least around 19200 baud, which really > looks less > > > dull. > > > > > In the attached graph, a minimum, maximum and > average has > > > been computed for each interval of ten millions > to make > > > straight lines visible. > > > > > Greets, > > > Kiste > > > > > P.S.: If someone is interested, I can send the > raw data by > > > email. The list of decimal numbers makes a text > of 20GByte, > > > but xz packs it to 15MByte. > > > > > P.P.S.: > > > Here's the "Hitlist" for print.jal: > > > > > Top values: | Bottom > values: > > > 1.: 48160 @ 757777777 | 58 @ > 0 > > > 2.: 48150 @ 737777777 | 5506 @ > 200000000 > > > 3.: 48140 @ 377777777 | 5515 @ > 100000000 > > > 4.: 48130 @ 697777777 | 5546 @ > 300000000 > > > 5.: 48126 @ 757777773 | 5596 @ > 700000000 > > > 6.: 48125 @ 757737777 | 5904 @ > 200000 > > > 7.: 48124 @ 757776777 | 5908 @ > 100000 > > > 8.: 48120 @ 357777777 | 5928 @ > 2000000 > > > 9.: 48116 @ 737777773 | 5932 @ > 1000000 > > > 10.: 48115 @ 737737777 | 5947 @ > 20000000 > > > 11.: 48114 @ 737776777 | 5954 @ > 300000 > > > 12.: 48110 @ 337777777 | 5956 @ > 10000000 > > > 13.: 48106 @ 377777773 | 5968 @ > 3000000 > > > 14.: 48105 @ 377737777 | 5987 @ > 30000000 > > > 15.: 48104 @ 377776777 | 5992 @ > 90000000 > > > 16.: 48100 @ 177777777 | 5994 @ > 700000 > > > 17.: 48096 @ 697777773 | 6008 @ > 7000000 > > > 18.: 48095 @ 697737777 | 6017 @ > 70000000 > > > 19.: 48094 @ 697776777 | 6325 @ > 1000 > > > 20.: 48092 @ 757777772 | 6326 @ > 2000 > > > 21.: 48091 @ 757737773 | 6349 @ > 10000 > > > 22.: 48090 @ 277777777 | 6350 @ > 20000 > > > 23.: 48089 @ 757736777 | 6366 @ > 3000 > > > 24.: 48086 @ 357777773 | 6390 @ > 30000 > > > 25.: 48085 @ 357737777 | 6410 @ > 7000 > > > > > And here for print_scalable.jal: > > > > > Top values: | Bottom > values: > > > 1.: 5225 @ 3999999991 | 104 @ > 0 > > > 2.: 5222 @ 3999999990 | 280 @ > 10 > > > 3.: 5198 @ 2999999991 | 283 @ > 11 > > > 4.: 5195 @ 2999999990 | 319 @ > 20 > > > 5.: 5188 @ 3899999991 | 322 @ > 21 > > > 6.: 5187 @ 3999989991 | 358 @ > 30 > > > 7.: 5185 @ 3899999990 | 361 @ > 31 > > > 8.: 5184 @ 3999989990 | 397 @ > 40 > > > 9.: 5181 @ 3999999890 | 400 @ > 41 > > > 10.: 5180 @ 3999998991 | 436 @ > 50 > > > 11.: 5177 @ 3999998990 | 439 @ > 51 > > > 12.: 5176 @ 3998999991 | 460 @ > 100 > > > 13.: 5173 @ 3998999990 | 463 @ > 101 > > > 14.: 5171 @ 1999999991 | 475 @ > 60 > > > 15.: 5169 @ 3999899991 | 478 @ > 61 > > > 16.: 5168 @ 1999999990 | 499 @ > 110 > > > 17.: 5166 @ 3999899990 | 502 @ > 111 > > > 18.: 5161 @ 2899999991 | 514 @ > 70 > > > 19.: 5160 @ 2999989991 | 517 @ > 71 > > > 20.: 5158 @ 2899999990 | 532 @ > 300 > > > 21.: 5157 @ 2999989990 | 535 @ > 301 > > > 22.: 5156 @ 3889999991 | 538 @ > 120 > > > 23.: 5154 @ 2999999890 | 541 @ > 121 > > > 24.: 5153 @ 2999998991 | 553 @ > 80 > > > 25.: 5151 @ 3979999991 | 556 @ > 81 > > > > > graph.png > > > 34KViewDownload- Hide quoted text - > > > > - Show quoted text - > > -- > You received this message because you are subscribed to the > Google Groups "jallib" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/jallib?hl=en. > > -- You received this message because you are subscribed to the Google Groups "jallib" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/jallib?hl=en.
