ROOL Forum: Recent Posts

Sat, 27 Jul 2024 07:46:48 -0000

Just sayin’ – this is something that you can use NOW with trivial source code and Makefile change, using your favourite (Norcroft) toolchain.

Sat, 27 Jul 2024 04:52:06 -0000

As an interpreted language geek I find that very pleasing.

Snap. Especially that endian conversion example. Although I’m not sure I’d ever find a use for it in anything I’m ever likely to do! 8~)

Fri, 26 Jul 2024 23:14:49 -0000

If you do go down the multi-path route in a program, where different code will be used depending on the machine it is run on, you are going to have to lock down your FP double format at an interfaces, such as file storage or network transmission, otherwise the program on a different machine wont read the data correctly. A common solution (also used where it might not just be endian differences) is to store/transmit FP as text strings.

Fri, 26 Jul 2024 21:53:27 -0000

As mentioned, most users wouldn’t notice any different – there’s a fair bit of overhead surrounding calls to calculations.

If the compiler could output VFP natively, then wouldn’t that remove a lot of the overheads?

that uses the fastest FP method available, on whichever platform the compiled object code runs on?

While it isn’t insurmountable, there are questions regarding the two having the data words in different order, not to mention a lot of noise and mess constantly branching for this or that. However, given the OS’ history, this sort of compromise may be the best option, provided the compiler has an option to only emit FPE or VFP as well. This will permit the programmer to choose the most appropriate setup for their program – for example something that requires capable modern hardware might want to stick with only VFP, something that barely uses FP could just stick with FPE to easily run on anything…

Fri, 26 Jul 2024 21:36:19 -0000

@Paul

The explanation was in the HELP in the above screenshot. Namely, bitwise access to integers:

=<num>[n] (literal square brackets): the boolean value of bit n.
=<num>[l:h]: the unsigned integer value of a bitfield.
=<num>[l TO h]: the signed integer value of a bitfield. If n,l,h<0, 32 is added.

So a%[0] is the boolean value of bit 0 of a% (ie 0 if clear, -1 if set); a%[4:6] is the integer value (0-7) of bits 4-6 of a%; a%[16TO23] is the signed value of bits 16-23, the third byte of the word; and a%[24:31,16:23,8:15,0:7] is an endianness-swapped version of a% – converting between little-endian and big-endian in one small expression.

The boolean single bit ops allow code like IF a%[4] AND NOT a%[7] whereas the bitfield list form allows arbitrary bit rearrangement.

As an interpreted language geek I find that very pleasing. Coupled with the array arrow operator, that means you can endian-convert an entire array with:

a%()=>a%()[24:31,16:23,8:15,0:7]

Fri, 26 Jul 2024 21:33:58 -0000

It’s BASIC, Paul, but not as we know it.

That photo? Looks like a pleasant place for a picnic.

Fri, 26 Jul 2024 21:04:09 -0000

Hmmm, that gravestone looks like it’s been standing in Binley Woods for about 6 months.

Fri, 26 Jul 2024 20:54:46 -0000

By virtue of having multiple code paths and producing very unoptimised code? Maybe, so long as you’re prepared for the FPA path to be slower than present.

Would this be an issue for systems with hardware FPA like the A7000+ or just with FPEmulator? My experience with GCC is that it produces much faster code on the RiscPC with soft float than it does with hard float, so being able to use a soft float ABI within SharedCLibrary should provide important gains on almost all machines regardless of age.

If this does get integrated into the stubs, that should make runtime selection of different code paths easier to implement.

Fri, 26 Jul 2024 18:42:18 -0000

Well, I’ve really no idea what is going on here.

Fri, 26 Jul 2024 18:31:34 -0000

Is VFP compliant with IEEE 754 in respect of accuracy?

Easy answer – yes. Does it have extended precision like FPA – no.

is it beyond the wit of man to make the DDE C compiler generate code that uses the fastest FP method available, on whichever platform the compiled object code runs on?

By virtue of having multiple code paths and producing very unoptimised code? Maybe, so long as you’re prepared for the FPA path to be slower than present. Currently Norcroft can produce a sequence of consecutive FPA opcodes that the FPEmulator doesn’t have to take an exception hit per opcode for, which might be harder for a mixed-output compiler to do. Also remember that FPA and VFP have different order words in their 64-bit double :-)

My library’s default is to detect VFP availability and use it if possible, falling back to using FPA opcodes to do the same job if not. My feeling was that this wasn’t too bad; ISTR RiscOSM being maybe 10% slower using the library in this mode on older systems (and of course faster on newer ones), so it was worth it for them to have two binaries, selected at run-time.

Fri, 26 Jul 2024 18:26:01 -0000

Is VFP compliant with IEEE 754 in respect of accuracy?

If it is, is it beyond the wit of man to make the DDE C compiler generate code that uses the fastest FP method available, on whichever platform the compiled object code runs on?