World: r4wp

I know it's possible to do it by using a tiny C code in a shared 
lib.
 - does that look like a problem?

It breaks the "fit all in one binary" REBOL philosophy, requires 
to compile it for each platform and maintain OS-specific code...Not 
a problem per se, but IMHO a sub-optimal solution, that's why I was 
interested in a possibly purely "internal" solution, in case I would 
have missed it.

The link?: no option doesn't seem to be available yet. Is it in the 
unreleased AVR backend?

It's available but not documented as it is only used by the compiler 
internally for now. You can add it to any of the target definition 
block in %config.r for testing (or create a %custom-targets.r file 
instead). It will put the compiler in an "incremental" mode (it can 
compile incrementally as many source file as you want). Once compilation 
has finished, no file will be generated and compiler state will not 
be reset. You can then inspect the result of the compilation from 
console using:

>> probe system-dialect/compiler/job
>> probe emitter/symbols
>> probe emitter/code-buf
>> probe emitter/data-buf
>> probe system-dialect/compiler/imports


You can basically get most of these data in logs when compiling using 
-v 9 option.

Cool, thanks

R3 extensions break that philosophy already, so go for it :)

Does not linking mean that no binary file is output, or does it also 
mean that addresses in the code are not resolved?

Only the latter.

You can link to something that only exists in RAM.

That can't be right

People overestimate what linking means. It really is as simple as 
a pointer, the same thing that it means in a linked list.

Kaj: that's right. If you want addresses to be resolved, we need 
to add a in-memory linker. It will basically just resolve all the 
addresses. But that would not work as is with the imports that expect 
to be statically linked. So, a custom dynamic loader would be required 
(same requirements as for implementing LOAD/LIBRARY and MAKE ROUTINE!).

Not a big deal to implement though, just time-consuming.

I know what linking is; I wrote a relocating loader in Atari 8-bit 
assembler

I don't mean external symbols that are for the operating system to 
resolve, I mean the internal linking that the Red/System linker, 
presumably %red-system/linker.r, does inside a Red/System compile, 
possibly consisting of multiple sources

To put it concretely, the AVR backend needs to generate a memory 
image, without external symbols because there is no operating system, 
but with all internal addresses resolved. Can that memory image be 
constructed by appending data-buf and code-buf?

Nope, you need to do some processing first. All global addresses 
in code are zeroed by default. The linker fills the blank by calculating 
the right code or data addresses.

It's basically what does linker/resolve-symbol-refs

OK. Any idea when you'll publish the AVR backend? It would be useful 
for reference

You mean the linker backend?

Yes, but anything that's fit for inclusion :-)

It's already published since several months: red-system/formats/Intel-HEX.r

Oh, great :-)

As you will notice, it uses a minimal C-based kernel and some imports 
are linked to it using syscalls.

An Arduino? I'll look into it

Yes, that's a kernel for a Arduino Uno board.

OK, great

I would like to get rid of the compiled C part, but never found the 
time to recode it in Red/System. It would also needs some addition 
to Red/System, like interruption handling (already planned) and other 
non-planned features, like a way to initialize RAM/SRAM from Flash 
memory (basically, it needs to copy the firmware data section from 
ROM to RAM), or initialize properly the timer clock (which should 
be doable with the hardware I/O support I've planned already).

In fact, once done, it would be the first nano-kernel written in 
Red/System. ;-)

Thanks, that's useful info

Here are the syscalls that should map to that kernel version (I've 
changed it often):

#syscall [
	init-runtime: 02F0h []
	
	init-serial: 05C8h [
		object	[int16!]
		baud	[integer!]
	]
	prin: 084Eh [
		object	[int16!]
		msg		[int16!]		; string pointer!
	]
	prin-int16: 09FEh [
		object	[int16!]
		value	[int16!]
		type    [int16!]		; unsure about the meaning of this parameter
	]
	prin-int32: 0992h [
		object	[int16!]
		value	[integer!]
		type    [int16!]		; unsure about the meaning of this parameter
	]
	set-pin-mode: 046Ah	[
		pin		[byte!]
		mode	[byte!]
	]
	digital-write: 04B6h [
		pin		[byte!]
		value	[byte!]
	]
	wait: 023Eh [
		delay	[integer!]
	]
]

The kernel does not use pure C, but Processing, a C/C++ hybrid.

Do you have int16! implemented in the AVR backend?

Well, I do have something, but it's messy, buggy and incomplete. 
I can send you the AVR8 backend if you want to play with it, I don't 
want to publish it until it gets a stable and correct support for 
basic datatypes.

I'll keep it in mind, but don't need it now

In Red/System, can I assign a value to a variable of different type? 
say    a: 1 a: "1"

Nope, Red/System is statically typed, you can never change the type 
of a variable. You can just do type casting to convert the variable's 
value to a compatible type.

Jerry, remember that variables are, semantically, just labels to 
variable-size containers in Red/System. The memory model is similar 
to C's one, so totally different from Red or REBOL.

I've activated the doc-strings in all the Red/System bindings that 
I had prepared when I wrote them

If someone writes the doc tool that Doc proposed, you could generate 
separate documentation for the bindings

I've removed the / from the repository name for the test binaries. 
Fossil was using the title in the download file names, so the slash 
was creating odd results

I can run the Windows executables under WINE on Linux. Oddly, cURL 
and SDL sound work there, so for now I'll blame Windows 7 for their 
failure there

Maybe I will take a shot at the tool. Outline would be handy and 
specs.

In allocator.reds, the only struct I know is cell. What are node 
and frame here? Doc.

Line 35:

#define node!				int-ptr!

The various frame struct!s are declared in lines 79, 86,and 94

Peter, I mean, What are they used for?

I guess it's not a good question. After all, I am not good at memory 
management. I should wait for Doc's Doc on Memory Management.

I think only Nenad understands that at the moment though the code 
in Unicode.reds may give some indight into using the Red Memory Manager.

indight -> insight