World: r4wp
[#Red] Red language group
older newer | first last |
BrianH 7-Nov-2012 [3410] | R3 extensions break that philosophy already, so go for it :) |
Kaj 7-Nov-2012 [3411] | Does not linking mean that no binary file is output, or does it also mean that addresses in the code are not resolved? |
BrianH 7-Nov-2012 [3412x2] | Only the latter. |
You can link to something that only exists in RAM. | |
Kaj 7-Nov-2012 [3414] | That can't be right |
BrianH 7-Nov-2012 [3415] | People overestimate what linking means. It really is as simple as a pointer, the same thing that it means in a linked list. |
DocKimbel 7-Nov-2012 [3416x2] | 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. | |
Kaj 7-Nov-2012 [3418x3] | 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? | |
DocKimbel 7-Nov-2012 [3421x2] | 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 | |
Kaj 7-Nov-2012 [3423] | OK. Any idea when you'll publish the AVR backend? It would be useful for reference |
DocKimbel 7-Nov-2012 [3424] | You mean the linker backend? |
Kaj 7-Nov-2012 [3425] | Yes, but anything that's fit for inclusion :-) |
DocKimbel 7-Nov-2012 [3426] | It's already published since several months: red-system/formats/Intel-HEX.r |
Kaj 7-Nov-2012 [3427] | Oh, great :-) |
DocKimbel 7-Nov-2012 [3428] | As you will notice, it uses a minimal C-based kernel and some imports are linked to it using syscalls. |
Kaj 7-Nov-2012 [3429] | An Arduino? I'll look into it |
DocKimbel 7-Nov-2012 [3430] | Yes, that's a kernel for a Arduino Uno board. |
Kaj 7-Nov-2012 [3431] | OK, great |
DocKimbel 7-Nov-2012 [3432x2] | 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. ;-) | |
Kaj 7-Nov-2012 [3434] | Thanks, that's useful info |
DocKimbel 7-Nov-2012 [3435x2] | 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. | |
Kaj 7-Nov-2012 [3437] | Do you have int16! implemented in the AVR backend? |
DocKimbel 7-Nov-2012 [3438] | 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. |
Kaj 7-Nov-2012 [3439] | I'll keep it in mind, but don't need it now |
Jerry 7-Nov-2012 [3440] | In Red/System, can I assign a value to a variable of different type? say a: 1 a: "1" |
DocKimbel 7-Nov-2012 [3441x2] | 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. | |
Kaj 7-Nov-2012 [3443x4] | 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 | |
Arnold 7-Nov-2012 [3447] | Maybe I will take a shot at the tool. Outline would be handy and specs. |
Jerry 8-Nov-2012 [3448] | In allocator.reds, the only struct I know is cell. What are node and frame here? Doc. |
PeterWood 8-Nov-2012 [3449x2] | Line 35: #define node! int-ptr! |
The various frame struct!s are declared in lines 79, 86,and 94 | |
Jerry 8-Nov-2012 [3451x2] | 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. | |
PeterWood 8-Nov-2012 [3453x2] | 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 | |
Pekr 8-Nov-2012 [3455] | Recent Red tweet: "All path datatypes (path!, lit-path!, set-path!, get-path!) implemented. " |
DocKimbel 8-Nov-2012 [3456x3] | Jerry: here is a quick overview: Red values are stored contiguously in series slots (128-bit cells). Series buffers are allocated from large chunks of memory of type series-frame!. Series value in slots store just a head offset and a pointer to a node!. The node! is another pointer to the series buffer. So series buffer are indirectly accessed, allowing them to be moved in memory (for reallocating with bigger/smaller size or moved by GC). |
A series buffer has header, with OFFSET and TAIL pointers that define respectively the begin and end of series slots. The OFFSET pointer allow to reserve space at head of the series for optimizing insertions at head. Series slots size can be 1 (binary/UTF-8/Latin-1), 2 (UCS-2), 4 (UCS-4) or 16 (value!) bytes wide. | |
From ~Links group: "Could Red eventually become a contender for #6? How strong will support for parallel processing be, eventually, in Red?" #6: yes, that is one of the goals I want to achieve with Red. For parallel processing, the model I have in mind is the "parallel collections" from Scala. This means that when you are looping over a series, Red should be able to parallelize the loop code over n (CPU and/or GPGPU) cores at the cost for the user of only a change of the loop function name (in Scala, they use a "par." prefix for such functions). This requires that the compiler do a deep static analysis of the loop body to determine if it can be parallelized (e.g. iterations not dependent on results from previous ones). Now, if you also add SIMD support in the equation to leverage intra-core parallelism, you get a good picture of what I want to achieve. ;-) So, I think a semi-assisted parallelization/vectorization of loops in Red is doable. To what extent and which final efficiency, I'm not sure before we build some prototypes. | |
NickA 8-Nov-2012 [3459] | To what extent and which final efficiency may be a key factor in your billionaire-worthiness ;) |
older newer | first last |