Hi Martin,
The code for <0 looks correct for both ARM and RISCV
a 0 value on the tos is not less than zero so the MSB of a 0 value doesn't
generate the true flag which is -1 (all bits set).
The ARM movs instruction is just used to set the condition codes without
disturbing the value on tos.
The RISCV architecture doesn't use arithmetic condition codes so doesn't
need the equivalent operation (movs).
The RISCV srai instruction does the equivalent by copying the MSB to
generate the true flag which is -1 (all bits set) if the tos value is less
than 0. So a tos value of 0 or greater will generate the false flag which
is 0.

Hope this helps
John S

On Mon, Dec 22, 2025 at 10:07 PM Martin Kobetic <[email protected]> wrote:

> I got the delays working on the uno r4, but while I was debugging I noticed
> that the word 0< (ZEROLESS) is actually '0 <= tos'. For ARM it's
> implemented as
>
> @
>
> -----------------------------------------------------------------------------
>   CODEWORD  "0<", ZEROLESS @ ( n -- ? )
> @
>
> -----------------------------------------------------------------------------
>   movs tos, tos
>   asr tos, #32    @ Turn MSB into 0xffffffff or 0x00000000
> NEXT
>
> (see
> https://github.com/mkobetic/amforth/blob/main/arm/words/comparisions.s#L41
> )
>
> The `asr tos, #32` (arithmetic shift right) shifts the sign bit over the
> entire register, so it does yield 0xffffffff or 0x00000000, but for 0 it
> yields 0x00000000, so it says that 0< is true for zero.
>
> I'm also wondering why is the `movs tos, tos` there, but that's separate
> from what seems like a bug to me. Am I correct? Do we want to fix this
> separately from my UNO R4 effort or should I just fix it in my fork for
> now?
>
> Looking at the RISC-V version it seems it may have the same issue
>
> #
>
> -----------------------------------------------------------------------------
>   CODEWORD  "0<", ZEROLESS # ( n -- ? )
> #
>
> -----------------------------------------------------------------------------
>   srai x3, x3, 31
>   NEXT
>
> Cheers,
>
> Martin
>
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>

_______________________________________________
Amforth-devel mailing list for http://amforth.sf.net/
[email protected]
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Reply via email to