Pito,
> In my newest float libs (1/2011) I am handling T this way - pushing
> an poping it into r14.7. It worked with 4.0 and 4.2. Is it possible
> you set the T in 4.0/4.2 within the inner interpreter only (it means
> before entering a word) and now you set the T anytime when interrupt
> fires- i
In my newest float libs (1/2011) I am handling T this way - pushing
an poping it into r14.7. It worked with 4.0 and 4.2. Is it possible
you set the T in 4.0/4.2 within the inner interpreter only (it means
before entering a word) and now you set the T anytime when interrupt
fires- it means maybe dur
Matthias, I do understand.. The point is not how huge the asm
snippets are, but that the .asm user cannot use the status register
freely. As the speed of the amforth is concerned, you know well the
floating point without fast asm. libraries is not usable. Maybe as a
floating point l'art pour l'art
Hi Pito,
> I need the Status Register as well, of course (;-)).
> It cannot be changed during an interrupt event (you are manipulating
> the T flag there).
That is part of the magic how the forth VM synchronizes interrupt
handling with the controller state. Its not a convential way, yes.
> Imagi
I need the Status Register as well, of course (;-)).
It cannot be changed during an interrupt event (you are manipulating
the T flag there). Imagine you run a routine and somebody changes a
flag there in SR. Would it be possible to use, as the interrupt
signalling, a bit outside the status register
I did not experienced such behaviour in 4.0 or 4.2. As you can
remember I did time measurements in a loop with ticktimer of most of
the asm floating primitives. No issues at that time. Now, when I
switch +timer it crashes. E.g.
> : test5 1 0 do 123 s>f 123 s>f f* fdrop loop ;
ok
> test5
ok
> +
Hi Pito,
> Hi, it seems the T flag is currently used in a much more "aggresive
> way".
Not at all. The usage of the T-Flag for dealing with
interrupts is part of the code for a very long time
(versions around 0.9). It is even documented since ever ;)
What's new, is that there is now an example fo
Hi, it seems the T flag is currently used in a much more "aggresive
way". The .asm floating routines are using T flag within sign
manipulation and when using timer (tick timer) and the float calcs
it does crash (e.g. do _float_asm_calc_ loop never finishes).
Q: when running a word e.g. f* written e
On Tuesday, May 24, 2011 07:54:08 PM Matthias Trute wrote:
> - The recognizer thing is now documented (to some degree);
> I sent an article to the German Forth FIG about it, that
> should be translated into plain English ASAP. Leons floating
> point library (a few patches are needed to work w
Hmmm, however it does not work when compiled:
> : test7 9.33e-1 8.334e+12 f* fp. ;
ok
> test7
3.402823E38 ok
> 9.33e-1 8.334e+12 f* fp.
7.775622E12 ok
>
Any hint from experts?? P.
- PŮVODNÍ ZPRÁVA -
Od: "pito"
Komu: amforth-devel@lists.sourceforge.net
Předmět: [Amforth] Recognize
Hi - this does work with my setup:
> marker -mycode
ok
> : rec-float count >float state @ if postpone fliteral then ;
ok
> .s
ok
> get-recognizer
ok
> .s
0 2005 3
1 2007 1562
2 2009 1532
3 2011 1593
ok
> : place-rec ( xt -- )
okget-recognizer
okdup >r
ok1- n>r
okswap
oknr> drop r> 1+
okset-rec
Hi, this is when we enter a little bit more decimal places -
probably a bug in >float or fsn.:
\ floating point input with >float, "& 1.23456e12"
: # bl word count >float not abort" NaN"
state @ if postpone fliteral then ; immediate
\ print 6 decimal places
: fp. 6 fsn. ;
> # 3.141592 fp.
3.14
for time beeing this still works with 4.4:
> : # bl word count >float not abort" NaN"
okstate @ if postpone fliteral then ; immediate
ok
> # 3.444e6 fs.
3.4439998E6 ok
> # 1.234e6 fs.
1.2337E6 ok
> # 123456789e10 fs.
1.23456776E18 ok
> # -1.3343e-12 # 6.222E22 f* fs.
-8.3020134E10 ok
> #
13 matches
Mail list logo
