World: r4wp
[#Red] Red language group
older newer | first last |
Kaj 25-Dec-2012 [4810x3] | Speaking about atomic operations, any thought to get them in Red/System? I could use them well |
Perhaps an atomic! type for an integer with guarantees about the generated code? | |
What are the chances that current integer operations already have atomic behaviour? | |
DocKimbel 25-Dec-2012 [4813x3] | I'm not sure what you mean by "atomic operation"? |
Red/System integer! operations are as atomic as the CPU permits. | |
Red/System maps its datatypes as closely as possible to the CPU (the same way C does). | |
Andreas 25-Dec-2012 [4816] | Re atomic operation: atomic "x: x + 1", for example. |
Kaj 25-Dec-2012 [4817x3] | Atomic means safe from corruptions by other CPU cores accessing the same memory |
http://syllable.cvs.sourceforge.net/viewvc/syllable/syllable/system/sys/include/atheos/atomic.h?view=markup | |
These become vital when you start doing multi-core concurrency | |
DocKimbel 25-Dec-2012 [4820] | Ok, I see what you mean. Like in C, you can already write "thread-safe" code in Red/System by using only variables on stack. If you need concurrent access to global variables, usually, the OS are already providing some API for that (locks, semaphores, mutex,...). I haven't chosen yet how it will be implemented at Red/System level, there are different options. For example, it could be handled by the language directly using a similar construct as in Java: synchronize [ x: x + 1 ] In my early design notes, I have researched only how to handle concurrency at Red level, I've left the underlying Red/System part as an "implementation detail". I plan to start working on it after I/O will be implemented. |
Kaj 25-Dec-2012 [4821x2] | I'm thinking about the case where you want to implement operating system level code yourself. For example, I have been fixing many bugs in Syllable's PThreads implementation, but I would like to replace it with a Red/System implementation. PThreads adds quite a few constructs that Syllable's kernel primitives don't implement as such, so to add them you need to write extra concurrency code |
For example, there are spinlock-like constructions in Syllable's PThreads implementation that can often prevent having to call a kernel mutex. This makes them much more efficient, but you need atomic operations on access flags and counters to implement the user-space spinlocks and mutex shells | |
DocKimbel 25-Dec-2012 [4823] | Modern CPU usually provide a way to make such atomic operations (e.g. CAS-type instructions), Red/System might provide access to them if it is required. |
Kaj 25-Dec-2012 [4824] | Something like that is what I have in mind. From what CPUs on are they supported? |
DocKimbel 25-Dec-2012 [4825] | From a quick googling, I've found: - x86: CMPXCHG (compare and exchange) is supported from 486. LOCK instruction seems to be available from PentiumPro only. - ARM: Starting with the ARMv6 architecture ARM has the LDREX/STREX instructions that can be used to implement an atomic compare-exchange operation. |
Kaj 25-Dec-2012 [4826x2] | So it would bump Red's requirements a little, but I guess it's worth it |
http://en.wikipedia.org/wiki/Compare-and-swap | |
Jerry 25-Dec-2012 [4828x2] | In current Red/System, there is no break/continue keywords (for loop), I wish they will show up in Red/System 2.0 |
So how can I break/continue a loop now? | |
DocKimbel 25-Dec-2012 [4830x2] | BREAK will probably be implemented before 2.0 (not sure for CONTINUE). So, you can't break from a loop currently. As a workaround, you can EXIT/RETURN instead. So if you write your loop in a separate function, you'll get similar effect as with BREAK. |
I'm a bit late for the Xmas release, sorry...still fixing bugs... | |
Kaj 25-Dec-2012 [4832] | I thought we already had a Xmas release :-) |
DocKimbel 25-Dec-2012 [4833x3] | Actually, it is not really a new release, as I did too many changes and it would need a week at least to stabilize and fully complete. But it will be a significant revision. ;-) |
revision = commit | |
I've stressed the current Red runtime source code a bit so it keeps "tilting" as I try to make it work. :-) | |
Jerry 25-Dec-2012 [4836] | Doc, will you spend some time making Red/Sys support loop BREAK/CONTINUE in the near future? or at least GOTO. Thanks. Programming without them is like drinking soup without a spoon ... |
DocKimbel 26-Dec-2012 [4837] | BREAK is on my todo list. I might add CONTINUE too. GOTO could be useful for implementing fast FSM, but having some specific feature for FSM support would probably be a cleaner option than GOTO. I personally very rarely need BREAK/CONTINUE, their usage depends on your programming style and the way you implement algorithms. |
Arnold 26-Dec-2012 [4838] | There are many way in which break and continue are being used amongst the different programming languages, most notable in case or switch statements. |
DocKimbel 26-Dec-2012 [4839x3] | BREAK in CASE/SWITCH statement is IMHO a very bad design choice leading to countless bugs. I'm glad Red and REBOL are doing it the right way. |
Xmas feature teaser: http://t.co/jTYwNzfb | |
Implementing that feature revealed a few deep bugs in the current Red runtime code, I hope to be able to finish fixing them by tonight. | |
Henrik 26-Dec-2012 [4842] | great stuff :-) |
Endo 26-Dec-2012 [4843] | Console support! I'm waiting for it impatiently!! BREAK/CONTINUE: I had to use those a few times in REBOL, it would be nice to have CONTINUE in Red too. |
NickA 26-Dec-2012 [4844] | Awesome Doc! Didn't expect to see a console so early. |
DocKimbel 26-Dec-2012 [4845x3] | It's a full REPL, so it's an interpreter + console. I was thinking about adding an interpreter since this summer in order to fill the gaps until the JIT-compiler will be there. Even when Red will gain JIT-compilation ability, for dynamic code with no loops, interpreting the code will be faster. Also, on some platforms, JIT-compilation is not allowed, so the interpreter will be handy to workaround those limitations. |
Now, you have a better picture about the "full-stack" approach of Red language. :-) | |
The console is currently just a Red script, once we get devices and ports, it will be replaced by a proper console:// port. | |
NickA 26-Dec-2012 [4848] | This will make it much easier for everyone to pick it up and experiment quickly and easily. |
DocKimbel 26-Dec-2012 [4849] | It still misses a lot of features, but I think it could be fairly complete (on par with Red compiler) in early January. |
Henrik 26-Dec-2012 [4850] | I guess all this means we have to think a bit more about how to benchmark things rather than simply profile code pieces directly in the console? |
DocKimbel 26-Dec-2012 [4851] | Right, if you bench from the console, currently, you're just measuring the speed of the interpreter. When the JIT will be there, loops from the console might get JIT-compiled, so it will be even less relevant to bench from the console. My plan since the beginning is to add a profiler to Red, so you'll be able to make precise comparisons whatever way the code is run. |
PeterWood 26-Dec-2012 [4852] | Great progress Nenad. |
Pekr 26-Dec-2012 [4853x2] | oh man, console, wooo hooo :-) |
so, what does it mean, in R/S and Red scenario, that console code is "interpreted"? | |
Arnold 26-Dec-2012 [4855x2] | Yes REBOL and Red do case/switch right way agreed! |
Great progress Nenad on this console. It must be getting more and more fun to use Red now!! | |
Andreas 26-Dec-2012 [4857x2] | Is the intepreter written in Red/System, or in Rebol? |
(Red/System or Red.) | |
DocKimbel 26-Dec-2012 [4859] | Red/System |
older newer | first last |