World: r3wp

thanks, works fine

If I have an #import function returning an integer! but I define 
it as logic! will that work properly, doing an implicit as-logic 
on the return value?

That would make some convenience wrappers unnecessary

Same error with CharToOem ...

Jocko: sorry to hear that, I will improve the fix I did yesterday 
right now.

Kaj: you can do an explicit casting, if is allowed by this matrix: 
http://static.red-lang.org/red-system-specs.html#section-4.7

Jocko: fixed by last commit: https://github.com/dockimbel/Red/commit/7b069cfefdf869cedfac9d2e1685c222320aaafd

I'm currently doing explicit castings, but that requires a wrapper 
function, which takes up space in the source and in every binary. 
So I was wondering if it would be a good idea to obsolete some of 
those wrappers

So you are asking to make the type system even weaker, I thought 
you were a proponent of strong typing ;-)

Could you solve is with defines? Something like: #define foo [as 
logic! _foo]

is => it

I don't think it would make typing weaker, because it is about the 
definition of external functions, that you have to believe on the 
blue eyes of the #import spec writer, anyway

C functions don't have a logic! type, so I would argue that defining 
one in a return type if you know the C function returns a compatible 
value actually makes typing stronger

A define would still generate code, so it wouldn't lead to reduction 
of source or binary size

The integer! -> logic! is not free, it implies generating extra code 
for converting properly (see the type matrix). So the define won't 
generate any more overhead than needed.

I just did a test using as-logic to convert an integer! returned 
by an imported function, it seems that the compiler is not generating 
the conversion code in such case...I need to investigate that issue 
deeper.

I'm fine with the extra code generated. It would be like inlining 
just one as-logic operation, and only generated when needed

The alternative is always going through the wrapper function, which 
is slower, and only for the as-logic, so this strikes me as a case 
where you would want to inline. The #import spec can be a nice syntax 
touch to signal that

Pushed a fix for the missing conversion code on type casting function 
call return value.

Right, as-logic will inline some conversion code only when required 
by the conversion rules from the type casting matrix.

I am considering your request for an implicit casting for imported 
functions using a return: [logic!] declaration. I could add it, by 
forcing a type conversion if the function is imported, but if the 
function already returns the right value (0 | 1), it will have to 
pay an extra cost for a useless conversion and no way to avoid it.

Like in the case where users would link to their own external libs, 
where return values are prepared specifically for Red/System.

So manually controlling the casting seems like a better option.

But then you have the overhead of the wrapper function

How about having return: [logic!] mean that 0 | 1 is returned, so 
no conversion is necessary?

Wrapper: not necessarily if you use a define as shown above.

The problem with that is that you have to do it for every function. 
It's more work, in a different place than the #import. It feels like 
a hack, whereas return: [logic!] lets the compiler know the exact 
type

Well, that is the default behaviour already. You just have to be 
sure that the imported function is respecting that convention strictly.

Besides, the #define would still generate the extra code, wouldn't 
it? There's currently no way to specify that no conversion is necessary 
for a return value

Just don't use any type casting and no conversion code will be added.

But will integer! than be handled as logic! in expressions?

Certainly not, but we were talking about an imported function with 
a return: [logic!] declaration?

Well, that was my original question, whether that already works as 
I would like :-)

So it can only be used when strictly 0 and 1 are returned in integer! 
format?

Exactly.

OK, thanks

If you function return 0 for false and a positive number for true, 
it needs a runtime conversion.

Fair enough

Any plans to implement automatic inlining in the future?

Yes, but probably as part of a future optimizing compiler version.

So, probably when Red/System will be rewritten in Red.

I would also adopt a fastcall convention as default for Red/System 
function calls.

Awaiting that, I'll refrain from the #define solution, then

Andreas, Kaj: what were the changes required on ELF emitter to make 
it work on Syllable? Just entry point address?

Base address, really, and address alignment

Ah, yes, base address, not entry point. Thanks.

Base address for Syllable Desktop is 80000000h which currently needs 
to be coded as -2147483648

The same change would be necessary for BeOS, by the way

Red/System can now generate dynamically linked ELF binaries.

Along with some additional pre-processor directives added (#if, #either, 
#switch), this now enables the Red/System runtime being fully writen 
in Red/System itself.