World: r3wp
[Red] Red language group
older newer | first last |
Geomol 21-Apr-2011 [1281] | Maybe NOT can be defined as a function this way? not: func [value][either none = :value or (false = :value) [true][false]] |
Dockimbel 21-Apr-2011 [1282] | Will Red implement operators in a fixed-predefined-set way like R2, or in a user-defineable way like R3? Op! will be user-defined as they were in R-sharp interpreter. Here's a short extract of R-sharp's boot script: +: make op! :add -: make op! :subtract *: make op! :multiply /: make op! :divide =: make op! :equal? <>: make op! :not-equal? |
BrianH 21-Apr-2011 [1283] | This would be safer to do in Red than it currently is in R3 because the compiler can perform all of the evaluation safety checks as part of its type checking, with no runtime overhead. |
Dockimbel 21-Apr-2011 [1284] | Exactly, safer and cheaper to do with a compiler. |
Andreas 21-Apr-2011 [1285x2] | If C doesn't allow struct parameters and return values, only struct references or pointers C allows struct values as parameters and return value. |
(They are often frowned upon in public API usage due to portability concerns, though.) | |
BrianH 21-Apr-2011 [1287] | Are there size limits to these parameters and return values? |
Maxim 21-Apr-2011 [1288] | ~size of the stack, I'd guess |
Andreas 21-Apr-2011 [1289x2] | yep |
no size limits, but it's obviously a lot easier to blow the stack if you pass around lots of large structs as values | |
BrianH 21-Apr-2011 [1291] | Even for return types? Are they just left on the top of the stack? |
Andreas 21-Apr-2011 [1292x6] | that depends :) |
as i said, it's a portability mess | |
small objects are sometimes passed in registers | |
i.e. if your struct fits in two machine words, some (x86) compilers use eax and edx to return it | |
other compilers rewrite the function to take an additional parameter with a pointer to storage used for returning the struct | |
(this pointer is then sometimes passed via a register, others pass it via the stack) | |
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 | |
older newer | first last |