Jump to page: 1 24  
Page
Thread overview
LLM's think we should have language tuples!
Mar 25
Manu
Mar 25
claptrap
Mar 25
Kagamin
Mar 26
Kagamin
Mar 30
Manu
Mar 30
Tim
Mar 27
ryuukk_
Mar 30
Manu
Apr 04
user1234
Apr 04
user1234
Apr 04
user1234
March 25
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


March 25
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

March 25
Well, yes: https://forum.dlang.org/post/nydunscuwdcinamqails@forum.dlang.org
March 26
Also LLM can be poisoned if it's given fake data: https://blog.cloudflare.com/ai-labyrinth/
March 27
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!)

March 27
Can also just scale up the long arithmetic asm routines that implement 32 bit arithmetic on the 16 bit x86.
March 27
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
March 27

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
March 27
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.
March 30
On Fri, 28 Mar 2025 at 02:16, Walter Bright via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> 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!)


I thought we had an arbitrary width float kicking around? I'm sure I've got one floating about somewhere...


« First   ‹ Prev
1 2 3 4