r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[Red] Red language group

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