World: r3wp
[Red] Red language group
older newer | first last |
BrianH 21-Apr-2011 [1298] | Would that behavior be standardized for a particular calling convention and ABI? For instance, that seems like the kind of thing that would have been standardized by stdcall or fastcall, but maybe not for cdecl or pascal. |
Andreas 21-Apr-2011 [1299x2] | afair it's a mess in all of them |
for x86 | |
BrianH 21-Apr-2011 [1301] | Sorry for all the questions - I haven't needed to write a C compiler yet. All the languages I've written compilers for or hand-compiled were really specific about this kind of thing. |
Andreas 21-Apr-2011 [1302x2] | on amd64, this is mostly fixed |
i have a handy reference by agner fog for intel platforms somewhere | |
BrianH 21-Apr-2011 [1304] | If you find the link, please post it :) |
Andreas 21-Apr-2011 [1305x4] | but the gist of it: x86 is fscked, x86_64 is much better :) |
here we are: http://agner.org/optimize/calling_conventions.pdf | |
table 6 in section 7.1 on page 19 sums up the mess that is struct passing :) | |
but beware, that is for c++ | |
Maxim 21-Apr-2011 [1309] | but we can say, in practice, that if Red doesn't support struct passed as value (or return)... no one is really going to notice. I have never actually seen code in the real-world which does this... simply because its very clumsy to do so. |
Andreas 21-Apr-2011 [1310x3] | (in this particular case, though, the situation is not much different for C) |
maxim: yes | |
Kaj: "I tested the new section headers on Syllable Desktop. memmap_instance() RO overlap RW (08048000 + 00001000 -> 08048000)" besides the entry point address being a problem, this could also be due to segment alignment, which we basically ignore, at the moment. could you try changing "page-size: 4096" to "page-size: 1" and see where that gets us? | |
BrianH 21-Apr-2011 [1313] | Judging by the tables, it looks like passing and returning structs in C is better done in internal code than in exported functions. There are too many exceptions and fallbacks. |
Kaj 21-Apr-2011 [1314x2] | I have to set the start address back to the Linux one to be able to compile with a changed page size |
A page size of 1 works on Linux, but on Syllable the load error is still exactly the same | |
Kaj 23-Apr-2011 [1316x2] | It seems logic! can't be used as a return value (last expression of a function) yet |
When I use NULL I get a smaller executable than with 0. Is that correct? The Windows backend emits four bytes, but the ELF backend says something about ignoring NULL | |
Dockimbel 23-Apr-2011 [1318x2] | NULL: a bit strange, need to check the sources for that. |
logic!: that's odd, see the 'foo function in test-logic.reds (foo: func [a [logic!] return: [logic!]][a]) | |
Kaj 23-Apr-2011 [1320] | Types aren't checked yet, are they? I currently have the return type defined as integer! |
Dockimbel 23-Apr-2011 [1321x2] | Right, not yet. But the return type is checked when the function is used in an expression. |
So, better get it right. | |
Kaj 23-Apr-2011 [1323x2] | That doesn't make it work, though |
-= Red/System Compiler =- Compiling /users/administrator/Red/reply-server.reds ... *** datatype not allowed at: [false] >> | |
Dockimbel 23-Apr-2011 [1325] | Strange...will look into that in a few minutes. |
Kaj 23-Apr-2011 [1326] | The difference may be between a variable and a constant |
Dockimbel 23-Apr-2011 [1327] | Have you redefined 'false? |
Kaj 23-Apr-2011 [1328x3] | No, I'm not that militant. :-) I do |
;#define no false #define no 0 | |
where false doesn't work | |
Dockimbel 23-Apr-2011 [1331] | I can't reproduce your issue here, can you give me a short example of a function making the compiler produce that error? |
Kaj 23-Apr-2011 [1332x2] | It must be this one: |
send: func [ ; Send message. socket [pointer!] data [pointer!] size [integer!] flags [integer!] return: [logic!] ; /local message [pointer!] ][ either zero? as-message message data size none none [ either zero? send-message socket message flags [ zero? end-message message ][ end-message message no ] ][ no ] ] | |
Dockimbel 23-Apr-2011 [1334x2] | Ok, will try with a similar pattern of code. |
Can't reproduce using: bar: func [a [integer!] b [integer!] return: [logic!]][ either zero? a [ either zero? b [ print "00" ][ print "11" false ] ][ false ] ] either bar 1 1 [print "KO"][print "OK"] either bar 0 1 [print "KO"][print "OK"] | |
Kaj 23-Apr-2011 [1336] | I'll try that |
Dockimbel 23-Apr-2011 [1337] | This test code compiles and works OK. |
Kaj 23-Apr-2011 [1338x2] | #define no false |
is what triggers it | |
Dockimbel 23-Apr-2011 [1340x4] | Ok, got it. |
It is probably a 'false word reduction issue. | |
(in the preprocessor) | |
Kaj, I've just pushed a commit that should fix your issue. | |
Kaj 23-Apr-2011 [1344] | Thanks! |
Kaj 24-Apr-2011 [1345] | The fix works; or at least it compiles now |
Maxim 25-Apr-2011 [1346] | Doc, did you consider using the set-word! type for getting pointers to words? much like we use them to get function values, instead of calling functions... |
PeterWood 25-Apr-2011 [1347] | http://groups.google.com/group/red-lang/browse_thread/thread/6a7438458d2d170b |
older newer | first last |