View Single Post
Old 30 December 2013, 13:02   #25
FrodeSolheim
FS-UAE Developer

FrodeSolheim's Avatar
 
Join Date: Dec 2011
Location: Førde, Norway
Age: 36
Posts: 3,368
Another thing, there is an alternative function interface we can consider - and I guess this was what Toni really suggested a bit earlier. I am warming to this as it becomes a more elegant esp. when one can share struct definitions on both sides. add_numbers would look like this then:

Code:
#pragma pack(2)
struct add_numbers {
    uni_char c;
    uni_short s;
    uni_long l;
    uni_long result;
};
#pragma pack()

UNIAPI void UNICALL add_numbers(struct uni *uni, struct add_numbers *params) {
    params->result = numbers->c + numbers->s + numbers->l;
}
All native functions would then receive two parameters (uni for interface information and UAE callback functions, and a params struct for the function parameters (and return value(s)).

You would then have to define a struct for each call (or use a common struct for simple calls), and all Amiga-side calls would need to set up a param struct and pass a pointer to it for any calls.

It isn't a really big difference to the current implementation where the same would be realized like this:
Code:
UNIAPI void UNICALL add_numbers(struct uni *uni) {
    struct add_numbers *params = (struct add_numbers *) UNI_PTR_PARAM(0);
    params->result = numbers->c + numbers->s + numbers->l;
}
It is a kind of trade-off: The former looks a lot cleaner for this example, but other simpler calls may look a bit simpler without having to declare param structs.

EDIT: important: I forgot to add byte-swapping macros to all add_number examples - it must be something like this:

params->result = UNI_SWAP_LONG(numbers->c + UNI_SWAP_SHORT(numbers->s) + UNI_SWAP_LONG(numbers->l));
FrodeSolheim is offline  
 
Page generated in 0.08645 seconds with 9 queries