Opened 6 years ago

Closed 14 months ago

#218 closed defect (fixed)

Bad C code generated with unboxed values

Reported by: erikd Owned by:
Priority: normal Milestone:
Component: Core to Sea Translation Version: 0.1.2
Keywords: Cc:

Description (last modified by benl)

The following code:

sillyTailCallFn :: Int32# -> Int32#
sillyTailCallFn count
 = counter 0#
	counter x = if x < count
		then counter (x + 1#)
		else x

main () = println (show (sillyTailCallFn 100#))

results in:

Main.ddc.c:35: error: assignment makes integer from pointer without a cast
Main.ddc.c: In function 'Main_sillyTailCallFn':
Main.ddc.c:62: error: assignment makes pointer from integer without a cast
Main.ddc.c:64: error: assignment makes integer from pointer without a cast
ddc: PANIC in Sea.Invoke

Change History (7)

comment:1 Changed 6 years ago by erikd

On the mailing list Ben said:

I think fixing this the "right way" will end up needing something like LibFFI I always hated the fact that we must use evaluation functions like to do general function calls.

Ideally, we'd change the format of the Thunk object that represents partial applications (defined in Object.h)

// A Thunk that represents a partial application.
typedef struct {
    uint32_t    tagFlags;
    PAD64       (Int32 pad);
    FunPtr      func;         // Pointer to the supercombinator of the function.
    uint32_t    arity;        // The arity of the supercombinator.
    uint32_t    args;         // Number of arg pointers stored in this thunk.
                              //	(ie, the length of the "a" array)
    Obj*        a[];          // Pointers to the arguments.
} Thunk;

Instead of just recording the arity of the supercombinator, we should have a bitfield to say what argument formats it accepts. We'd then change the code in Apply.c to read this bitfield, then use LibFFI to pass the appropriate arguments. Maybe we wouldn't need LibFFI for the LLVM backend.

Of course, if we store unboxed values directly in the Thunk then we also have to update the garbage collector. It would use the bitfield to determine where the pointers are. I don't think this would be hard to do, provided we had a nice API for decoding the bitfield.

Last edited 6 years ago by erikd (previous) (diff)

comment:2 Changed 5 years ago by benl

  • Milestone 0.1.3 deleted

Milestone 0.1.3 deleted

comment:3 Changed 5 years ago by benl

  • Component changed from Unknown to Core to Sea Translation
  • Milestone set to 0.3.0

comment:4 Changed 5 years ago by benl

  • Milestone changed from 0.3.0 to 0.4.0

This would have been the old lambda lifter setting the types of all parameters to Obj. We're not getting a new lambda lifter in 0.3.0, so pushing this back.

comment:5 Changed 3 years ago by benl

  • Description modified (diff)
  • Milestone 0.4.0 deleted

comment:6 Changed 14 months ago by benl

This is fixed in the new compiler. The source language does not expose raw unboxed values, so there's no need for a PAP to hold them directly.

comment:7 Changed 14 months ago by benl

  • Resolution set to fixed
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.