It is possible to implement fixed-point arithmetic in MikeOS ?
Emanuel Cabrera
Walt Nagel
Emanuel,
Do you mean fixed point or multi-precision. Although these two terms are somewhat related, they are different. In fixed point arithmetic binary 1 can represent almost any number: common values are 1/100 (0.01, e.g. cents), 1/2, 1, 2 or 10. Application specific numbers are then scaled by this common factor. Both the Basic and Forth applications provided with MikeOS are fixed point 1 systems. Most programmers write this kind of application without even thinking about it. (Note I would apply both math terms to the application code and not directly to the OS.)
MikeOS for the most part uses 16-bit registers for mathematics
('single' precision). However, it is configured to run only on
386 and newer processors. This makes it really easy for an
application programmer to include 32-bit ('double' precision)
mathematics routines. 64-bit ('quad' precision) math is also
possible with a little more effort.
If there are specific routines, within the scope of MikeOS (see the "System Developer Handbook"), that you have in mind, let the group know and they will be considered for the next release of the OS.
No apology for your English is necessary.
Walt
--
You received this message because you are subscribed to the Google Groups "MikeOS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mikeos+un...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/mikeos/e046d5c1-9e69-4f28-bd4f-73e52a13bb88n%40googlegroups.com.
Emanuel Cabrera
Walt Nagel
Such a library is probably beyond the scope of MikeOS, but as a separate, plug-in library it could be of interest. Instead of of trying to precisely calculate all the numbers from scratch I would suggest a simple look-up table of 90 integers. The software would determine the quadrant, sign and look-up pointer for sine and cosine. Tangent = 1000 * sine / cosine (a separate table is also possible). (The calculation is accurate to about 2 1/2 %.) Since division by zero is undetermined, I would return 65535 for tan(90) or cot(0).
I've attached a skeleton assembly file that could be used as a starting point for the library.
Walt
James Huddle
--
You received this message because you are subscribed to the Google Groups "MikeOS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mikeos+un...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/mikeos/1b93fa85-7184-ea39-ba32-ed4375c2f0c8%40yahoo.com.
Dan
Nice work! Something like this in a Math library could open the door to
all sorts of 3D shenanigans! It definitely makes sense to work in
degrees rather than radians here as you've done.
With `norm_alpha()` at a quick look you could spend a while looping to
reduce a value like 65k down the correct range, I would suggest to just
XOR once you have made it positive.
One thing I would suggest is that the table doesn't efficiently store
information about curves, you want more points around curves and less
points around lines if possible. A non-linear LUT in assembly might not
be ideal though.
Something to consider is just using an approximation. Given the accuracy
we're dealing with here, nobody will notice (just make sure it's
documented of course). For sine, something like the 'Bhaskara I's sine
approximation' could work [1].
Best of luck!
[1] https://en.wikipedia.org/wiki/Bhaskara_I%27s_sine_approximation_formula
Kind Regards,
Dan
> https://groups.google.com/d/msgid/mikeos/1b93fa85-7184-ea39-ba32-ed4375c2f0c8%40yahoo.com
> --
> You received this message because you are subscribed to the Google
> Groups "MikeOS" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to mikeos+un...@googlegroups.com
> <https://groups.google.com/d/msgid/mikeos/CAJh-HBGQTFbCKXF%3DNbCkQFn6et%3D3La9SMFLZErV83iqR-mR2OQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.
Emanuel Cabrera
Emanuel Cabrera
Walt Nagel
A Taylor series is an example of what I previously called a 'precise calculation.' Typically, for the sine a Taylor series would be given as sin(x) = x - (x^3/3!) + (x^5/5!) ... Raising to a power requires a lot of multiplications and the factorials would also require multiplications or a lookup table. The result would not be as accurate as a simple lookup table for many of the values of 'x' and the code would definitely be much more complicated and cpu time consuming.
This code needs tested, but here is what I quickly put together
for the simple lookup example:
; return sine of alpha
sin_alpha:
pushad
mov bp, sp
call norm_alpha
mov ebx, 1 ; set sign of result to +
cmp si, 180
jl .t1
neg ebx ; result is -
sub si, 180 ; alpha' = alpha - 180
.t1:
mov di, si ; a = alpha
cmp si, 90
jle .t2
mov di, 180 ; a = 180 - alpha
sub di, si
.t2:
shl di, 1 ; word entries
xor eax, eax ; zero extend
mov ax, [di+sin_table] ; get sin(a) from table
mul ebx ; set sign of result based on quadrant
mov [bp+4], eax ; return value to esi on stack
popad
ret
Most of the code is for determining the quadrant and adjusting the lookup angle accordingly. The actual lookup reduces to a single instruction.
Hope this is helpful,
Walt
--
You received this message because you are subscribed to the Google Groups "MikeOS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mikeos+un...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/mikeos/584a4c9b-d215-4425-a27a-427d94ed0548n%40googlegroups.com.