YOLOL chip limitations

riley

Learned-to-sprint endo
Joined
Jan 23, 2020
Messages
24
#1
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?
 

WolfiAUT

Active endo
Joined
Feb 18, 2020
Messages
32
#2
I think I read something about being able to safe the contents of a chip and copy it on another... well, if they allow copy/paste, I'd recommend you to have a few yolol codes safed on your pc/in your cloud.
 
Joined
Mar 12, 2020
Messages
4
#3
I think the intention is to make complexity in chip use difficult. The code for Yolol is very basic so anyone can use it, and limited so its difficult to abuse. At least thats what i'm getting from the information we have been supplied with.
 

kevinTOC

Active endo
Joined
Aug 9, 2019
Messages
36
#4
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?
* 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.
 

ST2005

Learned-to-sprint endo
Joined
Aug 9, 2019
Messages
22
#5
If in radius of 2 kilometers nobody is present, yolol will auto-disable. Also, on topic of 20 lines of code limits, it's unknown if "goto 51" statement work
 

riley

Learned-to-sprint endo
Joined
Jan 23, 2020
Messages
24
#6
* 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.
Wouldn't two chips running simultaneously cause a lot of concurrency issues? Do you know how they are solved? What is the ADS you were talking about?
 

riley

Learned-to-sprint endo
Joined
Jan 23, 2020
Messages
24
#7
I think the intention is to make complexity in chip use difficult. The code for Yolol is very basic so anyone can use it, and limited so its difficult to abuse. At least thats what i'm getting from the information we have been supplied with.
Abuse?
 

kevinTOC

Active endo
Joined
Aug 9, 2019
Messages
36
#8
Wouldn't two chips running simultaneously cause a lot of concurrency issues? Do you know how they are solved? What is the ADS you were talking about?
* Why should it cause issues? Those YOLOL chips are consistently repeating itself. If you have 1 line checking the ChipField, and repeating line 1 unless the ChipField has a specific value/string, it should be fine.
* ADS - Active Defense System. Like a CIWS on a warship.
 

ST2005

Learned-to-sprint endo
Joined
Aug 9, 2019
Messages
22
#9
Wouldn't two chips running simultaneously cause a lot of concurrency issues? Do you know how they are solved? What is the ADS you were talking about?
E2 chips in gmod are working fine. Including how buggy is wiremod and gmod itself, if E2 chips are working fine why should yolol break?
 

riley

Learned-to-sprint endo
Joined
Jan 23, 2020
Messages
24
#10
* Why should it cause issues? Those YOLOL chips are consistently repeating itself. If you have 1 line checking the ChipField, and repeating line 1 unless the ChipField has a specific value/string, it should be fine.
* ADS - Active Defense System. Like a CIWS on a warship.
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.
 
Last edited:

riley

Learned-to-sprint endo
Joined
Jan 23, 2020
Messages
24
#11
E2 chips in gmod are working fine. Including how buggy is wiremod and gmod itself, if E2 chips are working fine why should yolol break?
I'm not entirely familiar with E2 but maybe someone has tried what I mentioned above in it?
 

kevinTOC

Active endo
Joined
Aug 9, 2019
Messages
36
#12
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.
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.
 

ST2005

Learned-to-sprint endo
Joined
Aug 9, 2019
Messages
22
#13
I'm not entirely familiar with E2 but maybe someone has tried what I mentioned above in it?
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.
 

riley

Learned-to-sprint endo
Joined
Jan 23, 2020
Messages
24
#14
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.
If chips don't use the same fields or don't run at the same time then there wouldn't be an issue. I assume these chips would just handle different tasks?
 
Joined
May 18, 2020
Messages
4
#15
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.
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
 
Joined
Aug 9, 2019
Messages
1
#16
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.
 

MrFaul

Well-known endo
Joined
May 20, 2020
Messages
82
#17
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 ;-)
 
Joined
Aug 25, 2021
Messages
2
#18
If in radius of 2 kilometers nobody is present, yolol will auto-disable. Also, on topic of 20 lines of code limits, it's unknown if "goto 51" statement work
goto 51 is clamped to 20 so goto 1000000 will goto 20 as well... same goes for negatives goto-100 will goto 0, this is stated in the WIKI
 
Top