Re: [ql-users] Bug in SMSQ 312 maybe - or am I barking ?
On 22 Sep 2006, at 08:14, [EMAIL PROTECTED] wrote: Ok, A6,A1 was a typo, I meant A4 - apologies. On the other hand, my QDOS Companion (Pennell) has the load/save parameters as $32 to $ff and not $ff31 to $ as you state. I went on a doc hunt last night and Dickens has the negatives and my QDOS docs from Jochen also has negatives - so Pennell is wrong. Oh hum. Further to this, Dickens works out the actual address as (A6 + A4 + (D0.W OR FF00) AND FFEE) while Jochen's docs (in my version) simply has A6 + A4 + (D0.W AND FFFE) which looks like the correct verion - as only bit zero is cleared and not bits 0 and 1 as per Dickens. It is a long timne since I used the maths routines, but I made some notes on these and I found that they worked in practice. The op code are either in D0.W, for RI.EXEC or i a list of bytes, for RI.EXECB. This implies that the op code is a byte. Pennel thus refers to the range for fp number storage as $32 to $FE for reading and $31 to $FF for storage. Pennel further lists the addresses of the storage as -206 (A6,A4.L) to -2(A6,A4.L), I have interpreted that (correctly in practice) as $32 reading from -$CE(A6,A4.L) $34 reading from -$CC(A6,A4.L) . . . . $FE reading from -$02(A6,A4.L) Dickens says that codes $31 to $FF are extended to a negative word $FF31 to $ when used to determine the storage address. Apart from the fact that $31 does not seem to be allowed, Pennel and Dickens are saying the same thing in different ways, Pennel is in fact correct. Thus, there are only two bytes between each possible storage address so that storing fp numbers using,say, $32 and $34 is bound to lead to overwriting. George ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Bug in SMSQ 312 maybe - or am I barking ?
George Gwilt wrote: Dickens says that codes $31 to $FF are extended to a negative word $FF31 to $ when used to determine the storage address. Apart from the fact that $31 does not seem to be allowed, Pennel and Dickens are saying the same thing in different ways, Pennel is in fact correct. Yes, looking at the code, the upper byte is generated or derived from the lower byte, so it really doesn't matter whether it's $FF31 or $31, even though thinking of it as $FF31 makes it a) clearer and b) lends itself to the pointer arithmetic trick I did in my code sample. The problem here is that Minerva does OR the value with $FF00, which seems to be the desired result, while SMSQ/E sign extends the lower byte, which means that SMSQ/E will behave differently on the values $31 to $7F. Which could be considered a bug, I guess. Also, SMSQ/E defines the opcode $32 (push PI on stack), so the range effectively starts at $34 there ($33 actually, but that would be a store only location). Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Bug in SMSQ 312 maybe - or am I barking ? (OT ramblings about left and right)
According to Wikipedia, the story about Napoleon is legend with no basis in fact. However, what is interesting is that road traffic statistics seem to suggest that driving on the left is safer. The theory is that the preponderance of right eye dominance results in statistically faster reactions to oncoming traffic if you drive on the left. see http://en.wikipedia.org/wiki/Right_or_left_side_of_the_road#History so that makes left right, and right wrong! Jeremy (still lurking, rarely QLing these days) You see, the 'continentals' only drive on the right because they have copied America (which makes me wonder why France drives on the right - but hey !) Actually according to several sources France drove on the right before America made the switch from left to right after the War of Independence. Wikipedia even goes so far as to say that they not only did this to spite the British but to show gratitude to the French. Not sure how true that point really is though. Napoleon did the rest to spread right-side driving in Europe. So you see, we in the UK, Australia and so forth actually had first choice and led the way (ok, maybe not Australia, but we told them where to drive!) and everybody else copied the new and fashionable Americans :o) Well, historically using the left side made sense with all the swords hanging on the left side and enemies approaching from the right. But some parts of the world have moved on from there ;-) Frankly, the right is my good hand and I do prefer hanging the left uselessly out of the driver window while the other is doing all the hard work ;-) Cheers, Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Bug in SMSQ 312 maybe - or am I barking ? (OT ramblings about left and right)
In message [EMAIL PROTECTED], Jeremy Taffel [EMAIL PROTECTED] writes Jeremy (still lurking, rarely QLing these days) What, not even QL emulating ... :-) -- Malcolm Cadman ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Bug in SMSQ 312 maybe - or am I barking ?
Morning Marcel, Wolfgang, Thanks for your replies. Nope, that's where you differ with the documentation. First, the variable area is (A6,A4), typo I guess, and second, the opcodes $FF31 to $ are for load/save, not $32 to $FF. Yes, the latter DO work, but it seems that's more an undocumented side-effect. Ok, A6,A1 was a typo, I meant A4 - apologies. On the other hand, my QDOS Companion (Pennell) has the load/save parameters as $32 to $ff and not $ff31 to $ as you state. I went on a doc hunt last night and Dickens has the negatives and my QDOS docs from Jochen also has negatives - so Pennell is wrong. Oh hum. Further to this, Dickens works out the actual address as (A6 + A4 + (D0.W OR FF00) AND FFEE) while Jochen's docs (in my version) simply has A6 + A4 + (D0.W AND FFFE) which looks like the correct verion - as only bit zero is cleared and not bits 0 and 1 as per Dickens. Just look at the variable area as some kind of stack, with (A6,A4) pointing to the *top* of it. No problems with this now that I have the correct op code values. Now I had assumed that I could save one FP using code $32 and another using op code $34 and so on, but the source appears to indicate that I will overwrite part of my $32 saved FP with part of my $34 saved FP. Well, you can store other things in the variable area too, so it makes sense that you can address every individual word there. Not with the LOAD/SAVE op code as far as I can see, they always take 6 bytes from the A1 stack and load back 6 bytes. There is no way that I can see (using the maths package) to load and save a word for example. If I wanted to yuse the A4 stack as a general purpose buffer for words and things, I can do it without the maths package - so it doesn't make sense (to me). However, Dickens gives an example of the Hyperbolic Sine of a number (SINH) and in it he saves and loads values. His op codes are -6 and -12 for save_1 and save_2 - so obviously you *have* to use multiples of -6 for your save locations to avoid overwriting other stuff. Not only that, but codes from -5 through to -1 will overwrite data at the top of your A4 stack. Cheers, Norman. ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Bug in SMSQ 312 maybe - or am I barking ?
[EMAIL PROTECTED] wrote: Not only that, but codes from -5 through to -1 will overwrite data at the top of your A4 stack. Ignore that. I'm a pillock. I've got my mental stack upside down again :o( Cheers, Norman. ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Bug in SMSQ 312 maybe - or am I barking ?
[EMAIL PROTECTED] wrote: Morning Derek, Many years ago I wrote many Hyperbolic function based on The Advanced QL User Guide, by Dickens. All seemed to work fine. Funny that. I was just wondering if anyone had ever done that sort of thing when I was looking at Dickens last night. Spooky :o) I don't even know what one is ! I might have to look it up somewhere. Cheers, Norman. ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Bug in SMSQ 312 maybe - or am I barking ?
[EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: Not only that, but codes from -5 through to -1 will overwrite data at the top of your A4 stack. Ignore that. I'm a pillock. I've got my mental stack upside down again :o( Actually, I may not be a pillok after all ! Correct me if I'm wrong (again) but : (A6,A4) is a pointer to the TOP of my variables area - the highest address I want to use. Save code $ will get converted to a starting address of A6+A4+FFFE or A6+A4-2. The following code is then executed by the save to variables area : move.w (a1)+,(a4,d0.w) move.l (a1)+,2(a4,d0.w) ; store So, the word exponent of my FP gets written to -2(A6,A4) and the long word mantissa is written ABOVE my variables area at (A6,A4) for 3 bytes - oops. (Data written to -2(A6,A4) to +3(A6,A4)) Something similar happens at op codes $FFFD where we write to address -4(A6,A4) and overwrite one byte above the top of variables area (data written to -4(A6,A4) to +1(A6,A4)) So, in practice, the safest save op code has to be $FFFB (-5) which will safely write data into the variables area at -6(A6,A4) to -1(A6,A4) without exceeding the boundary set by my area TOP pointer of A4. I repeat my earlier (but slightly incorrect) observation that the code is broken. Because the load and save routines *always* copy 6 bytes around, we shouldn't be allowed to use load and save op codes that will break the system or corrupt other variables in the saved area etc. I'm looking forward to hearing back from you all :o) PS. I'm off to France next week, so any replies after today will be delayed in being read. I've got to drive on the wrong side of the road for a week - that should be fun. If you are anywhere around Marseilles, Carcasson, Aix-en-Provence then stay off the roads. Cheers, Norman. ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Bug in SMSQ 312 maybe - or am I barking ?
[EMAIL PROTECTED] wrote: I'm looking forward to hearing back from you all :o) PS. I'm off to France next week, so any replies after today will be delayed in being read. I've got to drive on the wrong side of the road for a week - that should be fun. If you are anywhere around Marseilles, Carcasson, Aix-en-Provence then stay off the roads. You must visit Minerve. I stayed there for a week in the 80s as a local vigneron said, in the house of of Madame Matteusse - it took a moment to realise he was saying Matthews (8-)# It was her son who loaned us the house, and as she was a local who married a Matthews, we were accepted as locals too. We were invited to an Asterix-like outdoor all day/evening feast organised by the local major and farmer. It was only after a while we realised everyone had brought some food - mussels from the Med, a whole lamb etc. We were all singers so I had a drunken drive back to M to collect madrigal books, and we gave them a concert! ... and wine around there is pronounced Ving with a hard end G - important to know (8-)# The French around there is Occitan - I suppose the equivalent of Geordie! Tony -- QBBS (QL fido BBS 2:252/67) +44(0)1442-828255 [EMAIL PROTECTED] http://firshman.co.uk Voice: +44(0)1442-828254 Fax: +44(0)1442-828255 Skype: tonyfirshman TF Services, 29 Longfield Road, TRING, Herts, HP23 4DG ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Bug in SMSQ 312 maybe - or am I barking ?
Thanks. (I think !!!) Cheers, norman. [EMAIL PROTECTED] wrote: At 10:41 22/09/2006 +0100, you wrote: Probably, I can see no connection ! -- ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Bug in SMSQ 312 maybe - or am I barking ?
[EMAIL PROTECTED] wrote: You must visit Minerve. We probably will - I'll be driving and MrsD will be navigating in her usual manner - you should have turned left back there ! (Only kidding) SNIP and wine around there is pronounced Ving with a hard end G - important to know (8-)# The French around there is Occitan - I suppose the equivalent of Geordie! Oh well. The problem with me is I don't speak much French - I hated it at school and couldn't get my head around it. Alison does a lot better than me though. We both have 'official' French from our formative educational years - but it bears no resemblance to anything actually spoken in France. Much like English in this country I suppose. Cheers, Norman. ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Bug in SMSQ 312 maybe - or am I barking ?
[EMAIL PROTECTED] wrote: Not with the LOAD/SAVE op code as far as I can see, they always take 6 bytes from the A1 stack and load back 6 bytes. There is no way that I can see (using the maths package) to load and save a word for example. Yes, but nobody tells you that the data area is just for FP data. So, the word exponent of my FP gets written to -2(A6,A4) and the long word mantissa is written ABOVE my variables area at (A6,A4) for 3 bytes - oops. (Data written to -2(A6,A4) to +3(A6,A4)) That is all correct. But I don't really see the problem here. Just don't write above your variable area if you don't want the value to be put there. ;-) I repeat my earlier (but slightly incorrect) observation that the code is broken. Because the load and save routines *always* copy 6 bytes around, we shouldn't be allowed to use load and save op codes that will break the system or corrupt other variables in the saved area etc. You still have total control over where the data is put. Just as a simple example (not tested, just written as-is): some_other_data dc.w$1234 my_fp_value dc.w0,0,0 some_more_data_in_between dc.w$abcd data_top [...] lea data_top(pc),a4 suba.l a6,a4 move.w #my_fp_value-data_top,d0 jsr qa.op PS. I'm off to France next week, so any replies after today will be delayed in being read. I've got to drive on the wrong side of the road for a week - that should be fun. You mean you'll be driving on the right side of the road. In both meanings for the word right ;-) Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Bug in SMSQ 312 maybe - or am I barking ?
Hi Marcel, Yes, but nobody tells you that the data area is just for FP data. True, but if I was setting up an area of storage I'd be sure (myself) to keep my FP stuff well away from my other stuff purely because it's possible for the FP stuff to wander all over my other stuiff if I get the offset wrong. It's not exactly documented anywhere really. Well not until QL Toady prints my next article where I have a good rant on the subject :o) Mind you, it allows someone more knowlegable that I am to comment in the next QL Toady about how wrong I am ! You still have total control over where the data is put. Just as a simple example (not tested, just written as-is): some_other_data dc.w$1234 my_fp_value dc.w0,0,0 some_more_data_in_between dc.w$abcd data_top [...] lea data_top(pc),a4 suba.l a6,a4 move.w #my_fp_value-data_top,d0 jsr qa.op Hmmm. That's interesting and looks quite clever too. I can see where you are coming from. When I read the docs, I was led (or led myself) into thinking that you have a 'stack' area where you keep your variables and that this area was purely used for the purpose. So I'd have an area of 6*N bytes where N is the max number of FPs I want to store and set A4 to point there (relative A6). Thanks. You mean you'll be driving on the right side of the road. In both meanings for the word right ;-) No - right and wrong :o) You see, the 'continentals' only drive on the right because they have copied America (which makes me wonder why France drives on the right - but hey !) and the Americans only drive on the right because they are decended from a group of English misfits (the pilgrim fathers I believe) who were turfed out of England some years ago. Then there was the little matter of the American War of Independence where they wre finally allowed to break all ties with England. Hence, they chose to drive on the opposite side of the road - just to be different. So you see, we in the UK, Australia and so forth actually had first choice and led the way (ok, maybe not Australia, but we told them where to drive!) and everybody else copied the new and fashionable Americans :o) ducks under desk and hides Now, if that's not politically correct . :o) Cheers, Norman. ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Bug in SMSQ 312 maybe - or am I barking ?
Marcel, Well, I myself have never used this and only read up on it after your questions... Much obliged - thanks ! The idea of my own column commenting on all the things I read that are wrong or at least not-quite-right has already crossed my mind, but then I'm lazy and currently don't have much time. ;-) You'd probably be surprised at just how much time is involved in writing an article, never mind a series. Most of my stuff has been 'thouroughly' researched before hand (well, I try to) and I still get it wrong. The upcoming article isn't all that long but has taken me over a week to get it to the stage it is at. Just because of what I have to check up on and get right. Well, historically using the left side made sense with all the swords hanging on the left side and enemies approaching from the right. But some parts of the world have moved on from there ;-) Nope, we'll always be ready for a good fight :o) Right, I'm off to the accountants now - VAT looming. Cheers, Norman. ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Bug in SMSQ 312 maybe - or am I barking ?
[EMAIL PROTECTED] wrote: I was explaining the SAVE and LOAD op codes for RI_EXEC and RI_EXECB where the top of stack floating point value is saved to a variables area at (A6,A1.L) or a new TOS is created by loading back from said area. The op codes for save are even in the range $32 to $FF and the load op codes are odd in the same range. Save with $32 and load the same value back with $33, save with $34 and load with $35 and so on. Nope, that's where you differ with the documentation. First, the variable area is (A6,A4), typo I guess, and second, the opcodes $FF31 to $ are for load/save, not $32 to $FF. Yes, the latter DO work, but it seems that's more an undocumented side-effect. Just look at the variable area as some kind of stack, with (A6,A4) pointing to the *top* of it. Now I had assumed that I could save one FP using code $32 and another using op code $34 and so on, but the source appears to indicate that I will overwrite part of my $32 saved FP with part of my $34 saved FP. Well, you can store other things in the variable area too, so it makes sense that you can address every individual word there. Not only this, but I'm effectively wasting the $32 bytes at the start of my buffer As said, it's supposed to be the other way round. But even if the offsets were positive, you could just move A4 by $32 bytes, no need to reserve empty space for the offset. Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
