Sorry if this has been posted elsewhere but I have been unable to find conclusive information on this. Are YOLOL chips always limited to 20 lines of code? If so that means that means as per another post I read about sharing state between chips, that large programs may need multiple chips if they use over 20 lines. Will there be any way to clone the contents of a chip to another then?
YOLOL chip limitations
- Thread starter riley
- Start date
* You have 20 lines of code in a YOLOL chip, and 3 types of chips that can handle increasingly complex functions. (From simple functions like simple logic, to Complex mathematical equations. Each line takes 0.2s to read, meaning you have a 5Hz clock speed. (This is far too slow for an ADS)
* You can use the device fields on Memory chips to save states, allowing multiple YOLOL chips to check the status of a certain device field by having f.inst. one YOLOL chip manipulate a Chipfield, and having another check the status of that Chipfield. It effectively allows you to run far larger scripts.
* IIRC, there have been rumors about possibly being able to copy/paste a chip in-game, but AFAIK this hasn't been confirmed.
* You can use the device fields on Memory chips to save states, allowing multiple YOLOL chips to check the status of a certain device field by having f.inst. one YOLOL chip manipulate a Chipfield, and having another check the status of that Chipfield. It effectively allows you to run far larger scripts.
* IIRC, there have been rumors about possibly being able to copy/paste a chip in-game, but AFAIK this hasn't been confirmed.
I misunderstood the situation you were talking about. I take it you meant that one chip executes code until it reaches the end and then flips the state of a field, to activate another chip with is constantly checking that field. That shouldn't have a race condition since the chips aren't running simultaneously.
It does raise the question of whether you could pull off chips running concurrently to achieve something similar to multiple cores running on a modern machine. If you have multiple chips accessing and mutating resources then you can run into issues with concurrency https://en.wikipedia.org/wiki/Mutual_exclusion. It can be very difficult to ensure that you don't have race conditions if there isn't an exclusive command on the chip to handle this. This is what I thought you meant initially.
It also does sound too slow to do anything like an ADS then.
It does raise the question of whether you could pull off chips running concurrently to achieve something similar to multiple cores running on a modern machine. If you have multiple chips accessing and mutating resources then you can run into issues with concurrency https://en.wikipedia.org/wiki/Mutual_exclusion. It can be very difficult to ensure that you don't have race conditions if there isn't an exclusive command on the chip to handle this. This is what I thought you meant initially.
It also does sound too slow to do anything like an ADS then.
Last edited:
I think the biggest issue with running YOLOL chips simultaneously is indeed timing. If you have one chip manipulating a ChipField, and another is supposed to check that ChipField while already running, it may cause issues with the Chip being unable to keep up with the ChipField changing. Having the YOLOL chips running sequentially would be likely a better alternative. Though, I would like to see/try running multiple Chips at once without issues.
I know that it was either urchin or some other ship with wall designated for yolols only. And they are working fine. Mind you, 6+ yolols on one wall.
Also, a squad of 1000+ ships in trailers don't interfere between each other. Though they are controlled by only one person thanks to yolol coding and autopilots, yolols are working actually fine.
Also, a squad of 1000+ ships in trailers don't interfere between each other. Though they are controlled by only one person thanks to yolol coding and autopilots, yolols are working actually fine.
- Joined
- May 18, 2020
- Messages
- 4
My understanding of how it would work is chip1 = c1, memory = m, chip2 = c2
Connection:
c1 - m - c2
Pseudocode:
c1: if value x in m is undefined, set to -1, run code save calculation result to x in m
c2: if x in m !== -1 run code using that value.
This effectively lets you generate x on chip1 and continue to perform operations with it on chip2
Connection:
c1 - m - c2
Pseudocode:
c1: if value x in m is undefined, set to -1, run code save calculation result to x in m
c2: if x in m !== -1 run code using that value.
This effectively lets you generate x on chip1 and continue to perform operations with it on chip2
There are still potential concurrency issues with parallel execution if you are not careful due to the purposefully undefined order of execution (the order in which chips are executed within a tick is not fixed, and can change at any moment).
For example, let says we have two chips with each looping through the following instructions :
Chip 1 : :x = :x++ goto 1 (the goto 1 is present only to ensure that the line is rune every tick)
Chip 2 : :y += :x goto 1
The expected natural way this setup would work is with each chip alternating execution, and as a result giving us the triangular number series.
However, due to the fact that the order of execution of chips can change, it is possible to have one of the chips executed twice in a row (ex: tick 1 - Chip 1, then Chip 2; Tick 2 - Chip 2, then Chip 1; in this exemple, Chip 2 is executed twice in a row).
This means that some value may be added twice, while some will be skipped entirely; resulting in an incorrect result.
Of course, it is possible to account for that by using safeguards, such as a proto-semaphore; but this still require us to be mindful of the potential concurrency issues that multi-chip yolol can have.
For example, let says we have two chips with each looping through the following instructions :
Chip 1 : :x = :x++ goto 1 (the goto 1 is present only to ensure that the line is rune every tick)
Chip 2 : :y += :x goto 1
The expected natural way this setup would work is with each chip alternating execution, and as a result giving us the triangular number series.
However, due to the fact that the order of execution of chips can change, it is possible to have one of the chips executed twice in a row (ex: tick 1 - Chip 1, then Chip 2; Tick 2 - Chip 2, then Chip 1; in this exemple, Chip 2 is executed twice in a row).
This means that some value may be added twice, while some will be skipped entirely; resulting in an incorrect result.
Of course, it is possible to account for that by using safeguards, such as a proto-semaphore; but this still require us to be mindful of the potential concurrency issues that multi-chip yolol can have.
I don't have alpha access but from what I've seen you need to view each YOLOL line as a individual expression while a chip is a "shared scope".
The game executes one line per "tick" however it is unclear to me if any state changes are carried out in the same tick.
It could very well be that those are only translated to the next tick. Also how and when those ticks are executed is up the the games YOLOL processor which makes pseudo parallelism possible but I wouldn't bet on it to be super reliable.
Regardless this could result in potential race conditions if two chips try to set the same variable so you have to build safeguards to prevent that.
A possible solution would be a 3 step variant:
1) C1 sets a empty V
2) C1 and C2 read V so C1 knows it is send and C2 recives
3) C2 resets V to null/0 in the next tick when read
Also please don't bring the E2 into this, while they feel similar I assure you they are not.
Unlike YOLOL E2 gives you control on how it is executed which allows whole other level of tomfoolery ;-)
The game executes one line per "tick" however it is unclear to me if any state changes are carried out in the same tick.
It could very well be that those are only translated to the next tick. Also how and when those ticks are executed is up the the games YOLOL processor which makes pseudo parallelism possible but I wouldn't bet on it to be super reliable.
Regardless this could result in potential race conditions if two chips try to set the same variable so you have to build safeguards to prevent that.
A possible solution would be a 3 step variant:
1) C1 sets a empty V
2) C1 and C2 read V so C1 knows it is send and C2 recives
3) C2 resets V to null/0 in the next tick when read
Also please don't bring the E2 into this, while they feel similar I assure you they are not.
Unlike YOLOL E2 gives you control on how it is executed which allows whole other level of tomfoolery ;-)