Compiled Powder Toy Language - CPT
-
Both cr15py and bchandark are idiots. He does not use binary counting in this. He uses decimal with 1's and 0's to represent it.
Anyway onto the main part!yew101:lol, im confused
Seconded! I havnt really read it much but.
Problem with this binary language (from first look) is that the inputs are not a standard length and some inputs are like 9 bits long. This would make it difficult to design a processor to handle. There is a language already which is 4bits and that is PCL which is based on devast8a's processor. Anyway it seems very confusing... -
massey101:He does not use binary counting in this. He uses decimal with 1's and 0's to represent it.
Decimal is base10, binary is base2. binary 00100100 (a standard byte) is decimal 36. Same as with Octal 044 and Hexidecial 0x24.
So he is still using Binary.
So massey101. you are the idiot.. -
Did this get noticed through a market product in the UNOFFICIAL Powder toy Shop
-
It is binary in that only 0 and 1 are used.
However, this language does not represent numbers in the standard binary fashion. It uses a series of base 10 digits, representing each digit using a specific sequence of 0s and 1s.
E.g. a number which in base 10 is 3 digits long would be represented using:
011-{base10digit}-11-{base10digit}-11-{base10digit}-110
Each {base10digit} is a string of 9 zeros, with the nth zero replaced by a 1, where n is the relevant base 10 digit.
(If separate base 10 digits really must be used, could they at least be in binary-coded decimal, which would take up a bit less room?)
My main concerns with this language are currently that:
- it is extremely (and unnecessarily) verbose and complex.
Storage (and probably processing) of verbose/complex information will take up much more room. Space is valuable in Powder Toy.
- the very variable length of commands is likely to make it more difficult to parse
- existing adders, subtractors, etc generally work in binary.
Although there is a valid reason for using base 10 digits for numbers (easier to display), I don't think this would outweigh the extra complexity and space needed to store them and perform arithmetic operations.
- Some codes are potentially a bit ambiguous. For example:
1011011000010000110....
1011 = start maths
011 = start number
000010000 = 5
110 = ??
What is this 110? Is it a 11 followed by the start of another digit, or a 110 followed by an arithmetic operator? There is no way of telling, without doing complicated things with the remainder of the code. Circuits should be able to parse it quickly, easily, and unambiguously, without looking ahead in the rest of the code to find out what a certain part of it means. -
Antb if he was using binary then 5 would be 00000101 not 00001000 notice how the 1 is the fifth from the right he is using 1's and 0's to represent a decimal system. Please dont talk about things you don't know about. And when I said binary counting I ment binary numbers which is were the confusion would of come from.
And diisaster although it's a clever system I do not think that it is within the scope of The Powder Toy to implement into a computer. If you can find a fast and efficient method of decoding then yes it would be good.
Edit: I would suggest having a mix between 5bit binary and decimal instead of the current decimal. Use the 5 bits to represent the numbers between 0-9 then do the thing you had to do the multiple places with the 11. -
110 is end number.
Update: Updating to base 10 -
UPDATE
to base11 -
Oh I see it's a programming language. I have some suggestions to things you should add the language.
* save in ram
* load from ram
* if
- greater than
- less than
- equal to
* jump
* display number
Note: I think it should compile to 4 bit and CPT++ should be 6 bit.
Now I understand completely and it is a good language. Maybe another character to use to signify position in ram. A allocated variable would be too hard to do.
