whartung wrote:
Of you could not bother exposing it at all and instead implement "IFU<" that does all of this internally.
U< IF is just one example. Forth is atypical in that you can use IF to create your own control structures. To branch backward you'd have UNTILU<. Then there'd be WHILEU<. Then you've got words like WITHIN < and > and so on, so you'd have IFWITHIN etc. It can get out of hand quickly. It may turn out that experimenting will suggest that defining IFU< on occasion is the way to go, but the purpose of the experiment is to see if there's a reasonably general approach (to operating on the carry flag) that doesn't make too much of a mess of things.
whartung wrote:
Granted this falls in to the "sufficiently smart compiler" trap, but the entire point of a higher level language is to abstract aspects such as this.
In my experience, embedded compilers (free or pay) aren't sufficiently smart enough, at least not yet, to really utilize the carry flag very effectively. Compilers don't yet seem to be able to turn a line like:
crc = (data & 0x80) ? ((crc << 1) ^ POLY) : (crc << 1);
into this:
Code:
ASL
BCC .1
EOR #POLY
.1
They can usually (under high enough optimization settings) eliminate an AND #$80 and use a BPL or BMI, but they don't use the carry. That's why it would be helpful to have a keyword (or something) that would tell the compiler to consider using the carry. The idea is that you'd use this new keyword on occasion to better communicate your intent to the compiler. You could use assembly in these cases, and in the example above it's short and simple, but if you've got to write one routine for the 6502, one for the AVR, one for the PIC, etc. it can add up quickly. I wouldn't expect a compiler to eliminate any need for assembly, but it seems to me that there's some room for improvement with the code currently generated by compilers in some reasonably common cases.
whartung wrote:
Forth chips don't have status flags either.
On Forth chips, pushing to and pulling from the data stack (usually) happens within a cycle, so there's no benefit to having flags. On the 6502, using flags does have benefit compared to pushing to and pulling from a data stack. Using, e.g., CLC is smaller and faster than pushing FALSE; if a pull can be eliminated, even better. But if it makes the high-level language that much more complex, it may not be worth it. That's what I'd try to learn from the experiment.