Thread overview
LLM's think we should have language tuples!
4 days ago
Manu
3 days ago
claptrap
3 days ago
Kagamin
2 days ago
Kagamin
1 day ago
Walter Bright
1 day ago
Walter Bright
1 day ago
Walter Bright
1 day ago
ryuukk_
4 days ago
I asked Grok to write me a portable 64x64->128 multiplication function in D to get the pattern, and this is what it wrote:

// Multiplies two 64-bit unsigned integers, returning a 128-bit result as
(low, high)
(ulong, ulong) mul64x64to128(ulong x, ulong y) {
    // Split into 32-bit halves
    uint x_l = cast(uint)x;
    uint x_h = cast(uint)(x >> 32);
    uint y_l = cast(uint)y;
    uint y_h = cast(uint)(y >> 32);

    // Compute partial products
    ulong p_ll = cast(ulong)x_l * y_l;        // Bits 0-63
    ulong p_lh = cast(ulong)x_l * y_h;        // Bits 32-95
    ulong p_hl = cast(ulong)x_h * y_l;        // Bits 32-95
    ulong p_hh = cast(ulong)x_h * y_h;        // Bits 64-127

    ulong low = p_ll;                         // Lower 64 bits
    uint p_lh_low = cast(uint)p_lh;
    uint p_hl_low = cast(uint)p_hl;
    uint p_ll_high = cast(uint)(p_ll >> 32);

    // Compute carry from middle terms
    ulong sum_mid = cast(ulong)p_lh_low + p_hl_low + p_ll_high;
    ulong carry = sum_mid >> 32;

    // Upper 64 bits
    ulong high = p_hh + (p_lh >> 32) + (p_hl >> 32) + carry;

    return (low, high);
}


What I loved is that its function returned a pair of ulong's, because apparently it made an assumption that we had in-language tuples! I wonder where it got that idea?

We should learn from our AI overlords! :P


3 days ago
On Tuesday, 25 March 2025 at 04:44:15 UTC, Manu wrote:
> I asked Grok to write me a portable 64x64->128 multiplication function in D to get the pattern, and this is what it wrote:
>
> // Multiplies two 64-bit unsigned integers, returning a 128-bit result as
> (low, high)
> (ulong, ulong) mul64x64to128(ulong x, ulong y) {
>     // Split into 32-bit halves
>     uint x_l = cast(uint)x;
>     uint x_h = cast(uint)(x >> 32);
>     uint y_l = cast(uint)y;
>     uint y_h = cast(uint)(y >> 32);
>
>     // Compute partial products
>     ulong p_ll = cast(ulong)x_l * y_l;        // Bits 0-63
>     ulong p_lh = cast(ulong)x_l * y_h;        // Bits 32-95
>     ulong p_hl = cast(ulong)x_h * y_l;        // Bits 32-95
>     ulong p_hh = cast(ulong)x_h * y_h;        // Bits 64-127
>
>     ulong low = p_ll;                         // Lower 64 bits
>     uint p_lh_low = cast(uint)p_lh;
>     uint p_hl_low = cast(uint)p_hl;
>     uint p_ll_high = cast(uint)(p_ll >> 32);
>
>     // Compute carry from middle terms
>     ulong sum_mid = cast(ulong)p_lh_low + p_hl_low + p_ll_high;
>     ulong carry = sum_mid >> 32;
>
>     // Upper 64 bits
>     ulong high = p_hh + (p_lh >> 32) + (p_hl >> 32) + carry;
>
>     return (low, high);
> }
>
>
> What I loved is that its function returned a pair of ulong's, because apparently it made an assumption that we had in-language tuples! I wonder where it got that idea?
>
> We should learn from our AI overlords! :P

Yeah but not on how to multiply integers.

It never adds the low 32 bits of "sum_mid", to the upper 32 bits of "low", plus it would also need to check if that overflowed.

something like...

ulong tmp = low + (sum_mid << 32);
bool carry_from_low = (tmp < low); //**
low = tmp;

then later: if (carry_from_low) high++;

**: if the result of the addition is lower than the initial value then it overflowed

3 days ago
Well, yes: https://forum.dlang.org/post/nydunscuwdcinamqails@forum.dlang.org
2 days ago
Also LLM can be poisoned if it's given fake data: https://blog.cloudflare.com/ai-labyrinth/
1 day ago
On 3/24/2025 9:44 PM, Manu wrote:
> I asked Grok to write me a portable 64x64->128 multiplication function in D to get the pattern, and this is what it wrote:

Cool! Now ask it to write an 80 bit IEEE floating point multiply!

(So we can cross compile from Arm to X86!)

1 day ago
Can also just scale up the long arithmetic asm routines that implement 32 bit arithmetic on the 16 bit x86.
1 day ago
On 3/27/2025 9:15 AM, Walter Bright wrote:
> Can also just scale up the long arithmetic asm routines that implement 32 bit arithmetic on the 16 bit x86.

https://github.com/DigitalMars/dmc/blob/master/src/CORE16/LMATH.ASM
1 day ago

On Thursday, 27 March 2025 at 17:31:54 UTC, Walter Bright wrote:

>

On 3/27/2025 9:15 AM, Walter Bright wrote:

>

Can also just scale up the long arithmetic asm routines that implement 32 bit arithmetic on the 16 bit x86.

https://github.com/DigitalMars/dmc/blob/master/src/CORE16/LMATH.ASM

here is what deepseek came up with:

To convert the provided x86 assembly code for 32-bit arithmetic operations to AARCH64, we leverage ARM's efficient instruction set for multiplication, division, and comparison. Here's the equivalent implementation:

    .section    .text
    .align      2

    .global     _LMUL@
_LMUL@:
    // Unsigned 32-bit multiply, result 64-bit in x0
    umull   x0, w0, w1
    ret

    .global     _ULDIV@
_ULDIV@:
    // Check for division by zero
    cmp     w1, #0
    beq     div0_unsigned
    // Perform unsigned division
    udiv    w2, w0, w1      // Quotient in w2
    msub    w3, w2, w1, w0  // Remainder in w3
    mov     w0, w2          // Return quotient
    mov     w1, w3          // Return remainder
    ret
div0_unsigned:
    // Handle division by zero: return (0xFFFFFFFF, 0)
    mov     w0, #-1
    mov     w1, #0
    ret

    .global     _LDIV@
_LDIV@:
    // Check for division by zero
    cmp     w1, #0
    beq     div0_signed
    // Perform signed division
    sdiv    w2, w0, w1      // Quotient in w2
    msub    w3, w2, w1, w0  // Remainder in w3
    mov     w0, w2          // Return quotient
    mov     w1, w3          // Return remainder
    ret
div0_signed:
    // Handle division by zero: return (-1, 0)
    mov     w0, #-1
    mov     w1, #0
    ret

    .global     _LCMP@
_LCMP@:
    // Compare two signed 32-bit values
    cmp     w0, w1
    b.gt    .greater
    b.lt    .less
    mov     w0, #0          // Equal case
    ret
.greater:
    mov     w0, #1          // Greater than
    ret
.less:
    mov     w0, #-1         // Less than
    ret
1 day ago
On Tuesday, 25 March 2025 at 04:44:15 UTC, Manu wrote:
> I asked Grok to write me a portable 64x64->128 multiplication function in D to get the pattern, and this is what it wrote:
>
> What I loved is that its function returned a pair of ulong's, because apparently it made an assumption that we had in-language tuples! I wonder where it got that idea?
>
> We should learn from our AI overlords! :P

Note: to get good results from AIs, ask them to write tests as well, then run the tests and post the answers and ask them to debug the issue. :) You have to handhold a bit.