cmp v teq

Always go straight ahead, unless you need to turn left or right;

One could say, “use either signed or unsigned at random, unless it matters one way or the other” but Rick’s rule is more sensible.

Nice one, Clive. ;-)

nemo – you would be surprised¹ how much code I’ve come across that:

• just “picks an integer” without considering whether signed or unsigned is more suitable
• compares an unsigned integer with <= zero
• (in BASIC) uses a float variable as a counter or flag
• functions that claim to turn an unsigned integer also claiming to return -1 on failure

My advice may seem stupid. But then so does “look both ways before crossing the road”. Some people might not realise that which seems obvious to us.

¹ Actually, you probably wouldn’t, I’m sure you’ve seen worse…

compares an unsigned integer with <= zero

Well, at least that works (it’s equivalent to comparing with = zero).

It’s comparing an unsigned integer with < zero that’s a bit pointless.

I’m sure you’ve seen worse…

Large negative R0 in OS_WriteC in a TaskWindow.

uses a float variable as a counter

Here’s an interesting thing (well, you may find it interesting). PostScript supports ‘integers’ and ‘reals’ – the precise definition is an implementation detail, but they’re typically 32bit and float. It also does automatic type coercion when parsing, so 1234567890 is an integer, but 2345678901 is a float (in a 32bit interpreter).

Now consider that the few commands/dictionaries that take a file offset will be parsed in the usual way, and that if the file is >2GB some file offsets are going to have a lot of digits… and so are going to end up silently being coerced into floats.

File offsets >2GB as floats are less useful than you might think. ISTR that the granularity of a float that’s just larger than MAXINT is 512 – so your file offset will be within 256 bytes of where it should be, but no more precise than that… and it can’t be incremented. So, not useful.

When a large integer is coerced into a float, it is probably just a number, and so should be a float, but if that number ends up being used as a file offset it’ll be: 1) the wrong type and 2) the wrong value. So how come you can use PostScript and PDF files >2GB in your non-Adobe RIP or Printer? I invented a cunning wheeze: XPFs.

When a large integer is coerced to a float, the difference between the precise integer and imprecise float is calculated and also stored in the float object. Then, if such an object is passed to a file operator, the full precision extended integer can be reconstructed… meanwhile everything else sees it as the imprecise float it’s supposed to be. Extended Precision Floats.

This isn’t an issue in Basic though, because Wilson was too clever to use floats. Basic reals are 40bit, not 32bit, so they can store up to twice MAXINT with a granularity of 1.

The other nice thing about Basic reals is that they’re big enough to store a 5-byte timestamp in (though not as a calculable value).

The other nice thing about Basic reals is that they’re big enough to store a 5-byte timestamp in.

Basalt uses them with its datetime keywords. ;-)

The other trick is to truncate the 5 byte to an integer, and then reconstruct the datetime with 128 (say) as the LSB – the result is accurate to within a second and a quarter. Often good enough, and that form is calculable.

I’m in the same camp as Rick…always use unsigned unless you specifically need negative numbers.

I’ve lost count of the number of sign misuse conditional instructions I’ve had to change whilst 32bitting games, it’s well into the thousands. It’s often not clear what the check is actually doing, so I waste days essentially figuring out what was going through the programmers mind when they coded it and adding the missing documentation back into code.

It’s for the VRPC Internet module.
There is a difference between working RO4.02 and RO5.25.

Checking out what they do – is part of the problem.
(should they be one or the other)

[Like motoring in France – which way to look at a junction] :-)

Looking at a way to automate some of it.

SWImi WriteRegPC ;or reporter swi

note where does the output go with WriteReg?

Was one idea?

where does the output go with WriteReg?

It’s just like the OS_Write* calls – via WrchV. eg:

SWI XOS_WriteI+4
SWI XOS_WriteI+30
SWI XWrite_PC
SWI XWrite_R0
SWI XWrite_R1
SWI XOS_WriteI+5

[Like motoring in France – which way to look at a junction] :-)

The way the French drive, you look at whatever way has a vehicle especially if you are on a more major road.

You may have seen the yellow lozenge sign? Those are put on departmental and national roads to mean you have right of way. Elsewhere, including main roads in many “agglomerations”, it should be assumed that the vehicle on the right has right of way. Even if this means a tractor pulling out of a lane directly into traffic.
It’s taking “right of way” to it’s illogical maximum.

Remember this when you see the many cars with bashed in right doors and left bonnets…

it’s well into the thousands.

As I pointed out earlier, on a 26 bit system, there’s no discernible difference between signed and unsigned comparisons because there’d never be a valid address with the high bit set.

I’m was guilty of this too – I just found GE/GT a better mnemonic than HI etc.
Still wrong though. ;-)

a better mnemonic

There is some aesthetic truth in this. Programmers are a weird bunch.

always use unsigned unless you specifically need negative numbers.

Something I remember from a while back, one of my YouTube downloaders used to give me file sizes for big things (like the Eurovision stream):

• 480P – something like 2GB
• 720P – something like -600MB
• 1080P – something like 100MB

Stunning example of using a signed 32 bit integer to try to hold an unsigned 64 bit integer.
<sigh>