From: Raymond Del Tondo on 17 Apr 2010 20:58 "Tom Lake" <tlake(a)twcny.rr.com> schrieb im Newsbeitrag news:hqddk4$hga$1(a)news.albasani.net... > > Hmmm. I've been programming since 1970 and have never run into BET in > thousands of FORTRAN, COBOL, BAL and BASIC programs. > I should have stated that I meant Saturn-based projects, but since we're in c.s.hp48;-) > Why would you put in a conditional if the program is always supposed to > branch at that point? > Because there are occasions where a conditional branch instruction uses less memory and less CPU cycles than an unconditional branch instruction. The languages you mention (except maybe BAL) are on a somewhat abstract level from the CPU point of view. If it comes to machine language, there are other priorities, at least from my experience. However even in S/360 assembly, we often used macros, which acted as an abstraction layer, but greatly eased life... Every hardware platform has its own special features, and there exist tricks for every platform and every language. One of the special features of the Saturn CPU (HP-48 and relatives) is that the carry can stay set as long as there is no instruction affecting it, and thus a GOC (GO on Carry set) can be used even some code lines below as long as the programmer knows that the carry will always be set when the code line is reached. And that's where the "BET trick" can be applied. In the NUT CPU (HP-41 and relatives) , the carry flag will only stay set for the next instruction, and always be cleared after the next instruction, so the "BET trick" can't be applied here. Cheers Raymond
From: Andreas Möller on 18 Apr 2010 03:48 Hello, > One of the special features of the Saturn CPU (HP-48 and relatives) > is that the carry can stay set as long as there is no instruction > affecting it, and thus a GOC (GO on Carry set) can be used even some > code lines below as long as the programmer knows that the > carry will always be set when the code line is reached. > And that's where the "BET trick" can be applied. Just for information please note that the "Saturnator" does not always behave like the original Saturn chip. I needed some real nasty debugging session to find this difference between the real Saturn and the "Saturnator". Wether it is a bug or a feature of the "Saturnator" is up to your point of view, but what is worse is that there is no documentation for the different behavior of the "Saturnator". So if you have a piece of Saturn-ML that works flawless on the 48 but behaves unexpected on the 49G+/50G you might want to check your carry flag. HTH some other in saving time if they stumble on this in their debugging session and do not find an explanation of what is going on... Regards, Andreas http://www.software49g.gmxhome.de
From: TW on 18 Apr 2010 09:36 > Wether it is a bug or a feature of the "Saturnator" is up to your > point of view, but what is worse is that there is no documentation for > the different behavior of the "Saturnator". > So if you have a piece of Saturn-ML that works flawless on the 48 but > behaves unexpected on the 49G+/50G you might want to check your carry > flag. I was a bug and was fixed in 2.15 from what I was told (unless you are talking about a new one you never told us about). TW
From: Han on 27 Apr 2010 18:24 I now have a fairly updated port of Jazz. There are several small issues that I am having at the moment, though. The behavior on the emulator is actually different than the behavior on the calculator! The keyboard handling routine acts differently (double-presses) on the calculator, whereas on the emulator, the correct behavior happens (only one key press). This shouldn't be the case, right? =-O
From: Andreas Möller on 27 Apr 2010 20:21 Hello, > This shouldn't be the case, right? =-O No, but as I tried to explain Emu48 and the Saturnator do not always behave the same, especially if it comes to ML and the carry flag. @Ttim: Did you test that fix ? I changed that code area so that I do not rely on the carry flag there anymore and as you know, testing on a real HP 50G is extremly time consuming (that´s the reason why I want a JTAG interface ;-) > The keyboard handling routine acts differently (double-presses) > on the calculator, whereas on the emulator, the correct behavior > happens (only one key press). Are you using your own keyboard routine or a built-in one ? The built-in routine of the 48 and the 50 are different IIRC, so if you rely on code that was original written for the 48 you might need some further adjustment for it. Remember that the 50G introduced some additional key handling features, like long hold shift. Maybe you could be a little bit more specific or even post the code, so that others can reproduce your problem. HTH, Andreas http://www.software49g.gmxhome.de
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 4 Prev: How to make $CONFIG not to be executed upon warmstart Next: using HP48 explorer release 1.1 |