In other news, the compiler can now compile slightly useful programs! if() and print() have been implemented, though the's no else or !=. And no loops yet. After that, GPU functions and user functions (right now it only compiles the "main" function).
Another limitation is this is a purely sequential compiler, there's no linker. This means you need to define all functions before you use them, like in languages such as lua.
The compiler's almost in a state where I can actually start using it to write programs instead of assembly. It has it's limitations, but it's much better than writing in assembly, and infinitely better than writing in machine code like you have to for most redstone computers.
What do you want to help with? The Java program? I don't think I need help at the moment, sorry. Everything's going almost perfectly with the compiler.
Correct, the robot class is used to input text into minecraft. You need a few delays here and there since the robot class is capable of typing way too fast for Minecraft.
In other news, this program:
num //only variable in program
function main:
{
num=10; //start counting at 10
print(num); //print it's initial value
until(num=0)
{
num=num-1; //decrease value
print(num);
}
}
successfully compiles into:
STO 10 22
DEB 22
:loop0
COP 22 0
STO 1 1
MT1 - 22
DEB 22
COP 22 0
COP 22 0
STO 0 1
IFF =1 loop0
END
which in turn successfully assembles into:
typing:scoreboard players set 0 ROMA 6
typing:scoreboard players set 0 ROMB 3
typing:scoreboard players set 0 ROMC 22
typing:scoreboard players set 1 ROMA 24
typing:scoreboard players set 1 ROMB 22
typing:scoreboard players set 1 ROMC 0
typing:scoreboard players set 2 ROMA 2
typing:scoreboard players set 2 ROMB 22
typing:scoreboard players set 2 ROMC 0
typing:scoreboard players set 3 ROMA 6
typing:scoreboard players set 3 ROMB 1
typing:scoreboard players set 3 ROMC 1
typing:scoreboard players set 4 ROMA 8
typing:scoreboard players set 4 ROMB 2
typing:scoreboard players set 4 ROMC 22
typing:scoreboard players set 5 ROMA 24
typing:scoreboard players set 5 ROMB 22
typing:scoreboard players set 5 ROMC 0
typing:scoreboard players set 6 ROMA 2
typing:scoreboard players set 6 ROMB 22
typing:scoreboard players set 6 ROMC 0
typing:scoreboard players set 7 ROMA 2
typing:scoreboard players set 7 ROMB 22
typing:scoreboard players set 7 ROMC 0
typing:scoreboard players set 8 ROMA 6
typing:scoreboard players set 8 ROMB 0
typing:scoreboard players set 8 ROMC 1
typing:scoreboard players set 9 ROMA 10
typing:scoreboard players set 9 ROMB 7
typing:scoreboard players set 9 ROMC 2
typing:scoreboard players set 10 ROMA 1
typing:scoreboard players set 10 ROMB 0
typing:scoreboard players set 10 ROMC 0
which then runs exactly as you expect it on the redstone computer!
Now, you don't need to be a genius to see that the assembly code isn't very well optimised (for example, "COP 22 0" appears twice right after each other, and many other less obvious issues) and that is kind of expected. I'll make it so you can actually manually manipulate registers in the high level language and use branch flags instead of compare options. You could even use assembly in the high level language, using asm("assembly code here"); , which will directly compile into that instruction. And of course, you can write a high level program and then edit the assembly code yourself.
So, if(), ifnot(), while() and until() all compile correctly. Now just user functions and I'm done with the main compiler stuff! Lots of bugs to fix and features to add after that of course.
Just overhauled the compiler after finding 2 major issues.
One was related to the lexer magically skipping tokens for no reason at all. Turns that, the code that analyzes code within if statement braces {} that was SUPPOSED to make a copy of a section of the List containing tokens, wasn't actually creating a copy, only a pointer.
Why, and how, does List.subList return a pointer to only a section of itself? I thought Java practically didn't have pointers! After searching for that bug for half an hour, I fixed it by changing it to "new ArrayList<>(data.subList(start, stop))".
I also completely replaced a section of the error handling system that's supposed to keep track of lines. If you want to tell the user there's an error on a specific line, you would probably track how many lines you've passed up until the point of the error, right? Well, that's actually a bad idea when tokens get manipulated and whole sections of tokens are given to other functions to compile, and those functions have no way of knowing how many lines came before it ran so you had to pass them a line offset argument telling them how many lines were before the given tokens. It was a complete mess, and it didn't even keep track of lines properly.
So, my solution was to store the lines in the tokens themselves. During tokenization, each token is assigned a line number corresponding to the line it was on when it was first read, and since this is passed along automatically to any function that deals with tokens, all they need to do for detecting line numbers is use "offendingToken.line". So I went through the over 600 lines of code dealing with compiling tokens and replaced the old method with the new one.
Also replacing the current poll with a new one about EEPROM allocation. Clearly I should build the controls level with the center, and the origin will remain bottom left. Thanks to everyone who voted!
What do you want to help with? The Java program? I don't think I need help at the moment, sorry. Everything's going almost perfectly with the compiler.
Anything really, I like your projects so I want to help if I can.
What's funny about Java is that people will say "Java doesn't have pointers," when in fact EVERY object reference is a pointer. You just can't do arithmetic on them and they automatically dereference so they're more or less invisible to the common coder.
In other news, compiler can now generate assembly for programs with user functions all on its own! User functions can have arguments, but there's no return values yet. Also making compiling a little easier with a GPU program that will be a compiler, assembler and code uploader in one. To go along with it, I've made a set of custom language rules for notepad++ for fancy syntax highlighting of my language, making coding easier and colourful.
That's exactly what a pointer is. A reference to something else, where the reference itself is passed by value. Hence everything in Java is a pointer.
Yet it copies the object and then points to that copy, therefore it isn't pass by value as shown in the example on Stackoverflow:
Object o = "Hello";
mutate(o)
System.out.println(o);
private void mutate(Object o) { o = "Goodbye"; } //NOT THE SAME o!
would print Hello, and not Goodbye were it a pointer.
I don't know, pointers are confusing, and I don't like how Java's trying to hide them. But I guess that's the very reason they hide them.
Anyway, I'm writing an optimisation stage for the compiler now. It will remove unnecessary COP and STO commands when values are already what they are being set to. For example, the following code:
var1=var1+1
var2=var2+1
would compile to something like this: (note: using variable names in assembly code for clarity, it doesn't actually look like this)
COP var1 A1
STO 1 B1
MT1 + var1
COP var2 A1
STO 1 B1
MT1 + var2
You may notice that "STO 1 B1" appears twice. this sets the value to add (in this case, 1) to the second value for ALU 1. Since both numbers are being added to 1, it's stored twice. But, since it's already 1 from the previous operation, this isn't needed.
This same issue seems to appear often, and for more than just simple math, so I'm trying to make something that detects this and removes the redundant "STO 1 B1". If my idea works, this should make compiled programs smaller and faster.
It should also remove unused functions, and could later do other optimisations if I feel like adding them.
Yet it copies the object and then points to that copy, therefore it isn't pass by value as shown in the example on Stackoverflow:
Object o = "Hello";
mutate(o)
System.out.println(o);
private void mutate(Object o) { o = "Goodbye"; } //NOT THE SAME o!
would print Hello, and not Goodbye were it a pointer.
I don't know, pointers are confusing, and I don't like how Java's trying to hide them. But I guess that's the very reason they hide them.
I feel kinda bad about being somewhat off topic in your thread, I didn't mean to start a whole conversation, so I'll stop after this.
That's not a great example because Strings are immutable (and interned, which causes other interesting behavior), and it's doing an assignment, not a mutation, so in fact mutate() is a misnomer.
If we use a mutable object like a java.awt.Point:
Point o = new Point(4, 6);
mutate(o);
System.out.println(o); // prints java.awt.Point[x=7,y=6]
private void mutate(Point o) {
o.x = 7; // THIS is a mutation; alters a part of an object
}
As you can see, it all works as expected.
If I added a o = new Point(5, 5); to mutate() after the mutation, it would still print (7, 6) because the reference is restored as it (and the new Point object) go out of scope when mutate() returns.
Good discussion here and here if you want to know more.
I'll stop mutating your thread (heh), but if you want help on your compiler I'd be willing, I like those kind of projects, recently wrote a CPU emulator myself.
Will we able to program games like pong or snake on this? Or is the GPU not fast enough to support that?
The GPU would be fast enough, but I'm not so sure about the CPU. Snake should be possible, though it would probably run really slowly, and tetris requires quite a bit of RAM manipulation, and I'm not sure if it would fit in memory. If tetris were possible, it would run incomprehensibly slowly.
Anyone know about that 2048 game? yea, that could be possible. It would run slowly as with everything else, but speed isn't really important in that game. though it would take ages to play...
Now, I don't mean to brag, but I believe I might be correct in saying this computer is the best minecraft computer to make games for. If it's ever going to happen, it's going to happen on this thing. Until, of course, someone makes a better one
...but if you want help on your compiler I'd be willing, I like those kind of projects, recently wrote a CPU emulator myself.
Ooh, a CPU emulator? which one? I'd love to see it!
I could use some help with the optimiser systems later I guess. And possibly later to allow for functions within arguments or more than one math operation at a time. The compiler's designed so I could possibly add them later, though I'm not sure if I will.
I'd also be willing to lend a hand
I started my compiler from the opposite side, starting with the maths expressions. As with everything I do, the hardest part goes first!
In my expression parser, I centered everything around the operator 'strength', so the expression gets reordered if the strength goes up, and keeps going if the strength goes back down. (I'm using accumulator-based assembly)
So this: a+b+c*d*e+f+g
Turns into this: c*d*e+f+g+a+b
if the strength goes up again, I push the previous section into a stack (done by the target computer) and reorder the next group.
once a bracket or endline is reached, the spliced expression is popped and added:
generated pseudo-assembly:
exp1
push
exp2
push
exp3
add
pop (exp2)
add
pop (exp1)
I then pass this to a parent function that deals with bracket ordering. (I'm working on that now)
That function uses this expression re-orderer on each bracketed element, and then recursively goes up in levels of abstraction by deleting the deepest bracket set and calling for another re-order.
Hope that's useful!
That's really cool, but my computer doesn't do stack based math, so it would need to store the half made equations in temporary variables. Good luck with your own computer!
As for computer updates:
finally replaced the 1D filler system with a command block one, plan A didn't work so I went with my original idea, which is slower, but actually works. So now the GPU's twice as fast. Colours are now actually variables, instead of being hardcoded in the instruction like they were.
STILL haven't gotten around to making a user input/output system, though the plans exist. I can also tell you that it will have a D-pad that you can read like 2 variables: Xpad and Ypad, Though they won't actually be variables, rather functions with a save to argument. The Xpad value would be 1 if you were standing on the right arrow, -1 if you were standing on the left arrow, and 0 if you were standing on neither. I'm sure you can guess how the Ypad will work. This will make it easier to write games, paint programs, or anything using both the D-pad and GPU.
And adding GPU functions to the language. Each function should have about 4 versions, one stand alone where it will use default colour and co-ordinates already in the registers, one with coordinates, one with only colour, and one with both coordinates and colour. And functions like gpu.point1(x,y) and point2, and setColour.
No video or pictures since there's not really much new to show, sorry!
Wow, working with dynamically changing memory is confusing and difficult to debug.
Just when I thought I fixed all local variable bugs, I find a new major one.Well, not really a bug, but rather unexpected behaviour. The assign argument function, assigning to argument 0 does not assign the first variable in a function, it actually assigns the last one with a value. Same with argument 1, assigning to the second last instead of the second. I completely forgot to test that and now that I'm trying to implement a line drawing algorithim I suddently wonder why it's not working at all.
Also, another problem: 64 ROM memory slots is way too small. It was OK for the Redgames, because coding was so tedious you never wrote complicated programs and instructions could do multiple things. Not the case here, where you can easily go over the program memory limit in minutes of writing high level code. The (untested) line drawing function I've written uses 75% of memory alone, and it's not even being called. I'll have to increase program memory size by a lot, how about 256 slots, or 3KB* of program memory?
Here's some demo programs I've written to test the compiler and faster GPU:
corridor:
x
y
function main:
{
GPU.clear();
x=1;
y=32;
until(x=16)
{
GPU.fill(x,x,y,y,x);
x=x+1;
y=y-1;
GPU.push();
}
}
stacked squares:
point1
point2
function main:
{
GPU.clear();
point2=10;//size of squares
point1=1;//starting point
until(point1=16)
{
gpu.rect(point1,point1,point2,point2,point1);//draw a rectange, colour defined by point1 for speed
point1=point1+3;
gpu.push();//render after it's been given some time
point2=point2+3;
}
}
(*256 slots *4 since scoreboard numbers are 32 bit *3 values per instruction=3072/1028=3KB. Not all 3KB actually usable in programs though)
I'm very interested in this project! I am interested in knowing how you are selecting the players when you read from the rom(s). Do you basically have a big decoder, or is there something else going on here? Thanks.
I'm very interested in this project! I am interested in knowing how you are selecting the players when you read from the rom(s). Do you basically have a big decoder, or is there something else going on here? Thanks.
Yes, it's just a big command block decoder. Basically "scoreboard players test romaddr system 2 2" for address 2, for example. Just a whole lot of those!
In other news, I've added a control room and user input! Also a new increment instruction, which is hard to explain but basically: varName+=5; used to take 3 instructions (store varname in A, store 5 in B, add A and B and store it in varname) but it's now a single instruction (add 5 to varname). This instruction can add or subtract any constant value to any variable, super useful in loops and stuff. The function can only add constants and store it at the same address it was originally in, if you want to increment by variables you need to use the ALU, but it's a whole lot faster and takes up less memory.
Compiler is working pretty well now, it's currently my main way of writing test programs. I only use assembly when debugging weird behaviour, which is occurring less than it used to. What's left now is the D-pad, arrays, some GPU framebuffer stuff (useful in saving and loading images, and basic collision detection), proper power controls, error detection (might add this after releasing and add it in a later version, not sure yet), and some documentation. There's a bit to do in the compiler as well, such as manual optimisation, some way to make arrays work, functions returning values, and some general stuff. I'd also need to document the languages...
Which reminds me, anyone have any ideas for a name for the programming language?
Hello guys!
I've talked a lot about my high level compiler, and now I've finally made a video of it!
Boot controller is done and working, everything is going smoothly (though halting and resuming a 2 stage pipeline was a tad more difficult than I thought)
I've still got to start on documentation, making manuals and stuff though. A lot of smaller details and stuff that I don't feel like doing yet need to be done as well. I'll also be doing a video tutorial series on programming it. So, just D-pad, misc GPU stuff and other small features, along with documentation to go!
Hello guys!
I know I'm not developing this as fast anymore, and that's because exams are coming up for me and I have other things to do. But fear not, I'm still working on this! Just not as much.
Anyway, it can now draw lines! not just vertical and horizontal lines, lines between any 2 points! (in other words, the full Bresenham's line drawing algorithm)
Along with some other features such as lighting changes on the screen, working D-pad, bugfixes, misc features...
oh yea, the GPU's gotten some updates. there's now a usable secondary framebuffer that you can use to save the state of the screen, restoring it later, and you can compare the stored and current framebuffer for some collision detection! The GPU also has 2 modes: traditional and double buffered, and can switch between them automatically or when the program wants it to.
I remember seeing your redgame 2 back ages ago, and having just coming back to minecraft after a year or so of the occasional play, with the goal of building a redstone cpu or maybe computer I think this is amazing. I've sort of popped in to see the major updates but missed most of the community creations so all the recent command block stuff I missed. The CPU's have been cool. But this is a step up. High level language is crazy. Also unconventionally implemented (at least back from my time).
How did you learn to make your first? I've sort of picked up the basics, but I'm no Von Neumann. I've ordered 'The Elements Of Modern Computing Systems', partly because I see a lot of cpu's designed with the HACK architecture and searching for 'Hack CPU' or 'HACK computer platform' comes up with 'How to hack a computer: 15 easy steps'. Not what I am looking for. I currently have an ALU. I think. I suppose it just qualifies as an ALU. It's more like a bunch of adders hooked up and some NOT's for subtraction. It's 16 bit but I only have the first 8 hooked up. Also it is HUGE. I'm working on RAM and registers although my RAM is just some small D-Flip flops stacked together.
From my understanding that qualifies...
It would be nice if we had some new info and tutorials on Redstone computers. The wiki stub is a stub. THe talk page said it was too technical. (I thought it was alright) But most CPU's are quite old. We have cool new stuff, and it seems a shame for complex redstone's legacy to lie in the mechanisms of old.
But anyway, great work here. Keep it up. L-OS is cool aswell, you clearly have a knack for this sort of thing.
I'll make a tutorial series explaining how computers work and how they're designed (or, at least, how I design them) eventually.
an ALU is a great start. All you need to do is adress the memory, so you can send it a binary signal and a pulse on a write or read line and have it write or read to the given adress. making seperate write and read decoders might help, but it's optional.
Then, you need a block of program memory (an array of decoders with their outputs going over lines where you place redstone torches above is what I did for all my computers until this one) and make a decoder for reading the instructions, routing the arguments to the read/write lines of the RAM and/or ALU mode controls, and send a read or write pulse to whatever needs it for that command. Then advance to the next one, and you have a working computer!
If you don't want a complicated program counter and branching system, you could use the "branch on every line" system the redgames used. Makes building easier, some programs faster, but writing programs becomes a little more tedious.
In other news, I'm allowing more low level instructions to be written in the high level language so you can easily optimise your programs while still keeping the code you haven't yet optimised in high level. It could also make "porting" your program to assembly a little simpler.
And it allows you to use ALU2! Until now, the compiler routed all math to ALU1, but now...well, it still actually does that. But you can manually use ALU2 though!
Here's what the "medium level" functions look like:
A1=bla;
B1=5;
mul1(ans);
is identical to:
ans=bla*5
when assembled. To use ALU2:
A2=bla;
B2=5;
mul2(ans);
This allows you to keep values you use often in computations in one ALU while doing less common math in another. Or have both store X and Y coordinates or whatever. Point is, this could make stuff faster.
Talking about making stuff faster, I'm now optimising the line drawing algorithm to use both ALUs and some other tricks.
Alright, development's going pretty slow now, but it's still going! I have exams here which means I have a lot less time to work on it these days.
Anyway, the high level programming language's main features are done; break, continue and return are now implemented. Functions can also now return values to the calling function. The following program works now:
lol//random variable I'll use to store the answer made by add
function add:
num1
num2
ans
{
ans=num1+num2;
return ans;
}
function main:
{
lol=add(5,6);
print(lol);
}
It prints out 11, as you would expect. It assembles to this:
SAR 5 2
SAR 6 1
ES 3 func0
COP 21 23
DEB 23
END
:func0
COP -1 0
COP -2 1
MT1 + -3
COP -3 21
DS 3
DS 3
Note the 2 "DS 3"s. This is Drop Stack 3, meaning leave a function and unallocate 3 local memory cells. There's 2 because the top one is the return function I called, and the other is the "normal" return that's appended at the end of every function. Clearly, this is redundant and should be removed by the optimiser later.
"COP -3 21" stores the output of the function to the temporary register (address 21 is used by my compiler for all temporary values). Then, "COP 21 23" copies it to var 23 (lol) and "DEB 23" prints out this variable. This could of course be compacted to "DEP 21", but that would be a tad to complex for the optimiser to detect. So it's not perfect, but since it can generate assembly code you can manually optimise it yourself if you know what you're doing.
Hay what aboutthe downloud?
ps ime still working on my GPU, mine is 64*64 pixels and runs fine even on my grandperants old windows vista 32 bit computer.
I remember seeing your redgame 2 back ages ago, and having just coming back to minecraft after a year or so of the occasional play, with the goal of building a redstone cpu or maybe computer I think this is amazing. I've sort of popped in to see the major updates but missed most of the community creations so all the recent command block stuff I missed. The CPU's have been cool. But this is a step up. High level language is crazy. Also unconventionally implemented (at least back from my time).
How did you learn to make your first? I've sort of picked up the basics, but I'm no Von Neumann. I've ordered 'The Elements Of Modern Computing Systems', partly because I see a lot of cpu's designed with the HACK architecture and searching for 'Hack CPU' or 'HACK computer platform' comes up with 'How to hack a computer: 15 easy steps'. Not what I am looking for. I currently have an ALU. I think. I suppose it just qualifies as an ALU. It's more like a bunch of adders hooked up and some NOT's for subtraction. It's 16 bit but I only have the first 8 hooked up. Also it is HUGE. I'm working on RAM and registers although my RAM is just some small D-Flip flops stacked together.
From my understanding that qualifies...
It would be nice if we had some new info and tutorials on Redstone computers. The wiki stub is a stub. THe talk page said it was too technical. (I thought it was alright) But most CPU's are quite old. We have cool new stuff, and it seems a shame for complex redstone's legacy to lie in the mechanisms of old.
But anyway, great work here. Keep it up. L-OS is cool aswell, you clearly have a knack for this sort of thing.
Dude you cant build a redstone computer (or any computer for that matter) unless you undedrsdand computer arckitecture.
Again, I am willing to help. :-)
THE MICRO$OFT APOCALYPSE IS ON!!!
32 bit redstone computer with 64*64 pixel 16 color gpu:
http://www.minecraftforum.net/forums/minecraft-discussion/redstone-discussion-and/2116999-computer-command-block-computer-now-running-with
(giant banner removed out of modesty).
The Robot class.
What do you want to help with? The Java program? I don't think I need help at the moment, sorry. Everything's going almost perfectly with the compiler.
Correct, the robot class is used to input text into minecraft. You need a few delays here and there since the robot class is capable of typing way too fast for Minecraft.
In other news, this program:
Now, you don't need to be a genius to see that the assembly code isn't very well optimised (for example, "COP 22 0" appears twice right after each other, and many other less obvious issues) and that is kind of expected. I'll make it so you can actually manually manipulate registers in the high level language and use branch flags instead of compare options. You could even use assembly in the high level language, using asm("assembly code here"); , which will directly compile into that instruction. And of course, you can write a high level program and then edit the assembly code yourself.
So, if(), ifnot(), while() and until() all compile correctly. Now just user functions and I'm done with the main compiler stuff! Lots of bugs to fix and features to add after that of course.
One was related to the lexer magically skipping tokens for no reason at all. Turns that, the code that analyzes code within if statement braces {} that was SUPPOSED to make a copy of a section of the List containing tokens, wasn't actually creating a copy, only a pointer.
Why, and how, does List.subList return a pointer to only a section of itself? I thought Java practically didn't have pointers! After searching for that bug for half an hour, I fixed it by changing it to "new ArrayList<>(data.subList(start, stop))".
I also completely replaced a section of the error handling system that's supposed to keep track of lines. If you want to tell the user there's an error on a specific line, you would probably track how many lines you've passed up until the point of the error, right? Well, that's actually a bad idea when tokens get manipulated and whole sections of tokens are given to other functions to compile, and those functions have no way of knowing how many lines came before it ran so you had to pass them a line offset argument telling them how many lines were before the given tokens. It was a complete mess, and it didn't even keep track of lines properly.
So, my solution was to store the lines in the tokens themselves. During tokenization, each token is assigned a line number corresponding to the line it was on when it was first read, and since this is passed along automatically to any function that deals with tokens, all they need to do for detecting line numbers is use "offendingToken.line". So I went through the over 600 lines of code dealing with compiling tokens and replaced the old method with the new one.
Also replacing the current poll with a new one about EEPROM allocation. Clearly I should build the controls level with the center, and the origin will remain bottom left. Thanks to everyone who voted!
Anything really, I like your projects so I want to help if I can.
Yet, at the same time, nothing is a pointer; it's all pass by value (see top answer: http://stackoverflow.com/questions/1068760/can-i-pass-parameters-by-reference-in-java )
In other news, compiler can now generate assembly for programs with user functions all on its own! User functions can have arguments, but there's no return values yet. Also making compiling a little easier with a GPU program that will be a compiler, assembler and code uploader in one. To go along with it, I've made a set of custom language rules for notepad++ for fancy syntax highlighting of my language, making coding easier and colourful.
That's exactly what a pointer is. A reference to something else, where the reference itself is passed by value. Hence everything in Java is a pointer.
Yet it copies the object and then points to that copy, therefore it isn't pass by value as shown in the example on Stackoverflow:
would print Hello, and not Goodbye were it a pointer.
I don't know, pointers are confusing, and I don't like how Java's trying to hide them. But I guess that's the very reason they hide them.
Anyway, I'm writing an optimisation stage for the compiler now. It will remove unnecessary COP and STO commands when values are already what they are being set to. For example, the following code:
would compile to something like this: (note: using variable names in assembly code for clarity, it doesn't actually look like this)
You may notice that "STO 1 B1" appears twice. this sets the value to add (in this case, 1) to the second value for ALU 1. Since both numbers are being added to 1, it's stored twice. But, since it's already 1 from the previous operation, this isn't needed.
This same issue seems to appear often, and for more than just simple math, so I'm trying to make something that detects this and removes the redundant "STO 1 B1". If my idea works, this should make compiled programs smaller and faster.
It should also remove unused functions, and could later do other optimisations if I feel like adding them.
I feel kinda bad about being somewhat off topic in your thread, I didn't mean to start a whole conversation, so I'll stop after this.
That's not a great example because Strings are immutable (and interned, which causes other interesting behavior), and it's doing an assignment, not a mutation, so in fact mutate() is a misnomer.
If we use a mutable object like a java.awt.Point:
As you can see, it all works as expected.
If I added a o = new Point(5, 5); to mutate() after the mutation, it would still print (7, 6) because the reference is restored as it (and the new Point object) go out of scope when mutate() returns.
Good discussion here and here if you want to know more.
I'll stop mutating your thread (heh), but if you want help on your compiler I'd be willing, I like those kind of projects, recently wrote a CPU emulator myself.
The GPU would be fast enough, but I'm not so sure about the CPU. Snake should be possible, though it would probably run really slowly, and tetris requires quite a bit of RAM manipulation, and I'm not sure if it would fit in memory. If tetris were possible, it would run incomprehensibly slowly.
Anyone know about that 2048 game? yea, that could be possible. It would run slowly as with everything else, but speed isn't really important in that game. though it would take ages to play...
Now, I don't mean to brag, but I believe I might be correct in saying this computer is the best minecraft computer to make games for. If it's ever going to happen, it's going to happen on this thing. Until, of course, someone makes a better one
Ooh, a CPU emulator? which one? I'd love to see it!
I could use some help with the optimiser systems later I guess. And possibly later to allow for functions within arguments or more than one math operation at a time. The compiler's designed so I could possibly add them later, though I'm not sure if I will.
That's really cool, but my computer doesn't do stack based math, so it would need to store the half made equations in temporary variables. Good luck with your own computer!
As for computer updates:
finally replaced the 1D filler system with a command block one, plan A didn't work so I went with my original idea, which is slower, but actually works. So now the GPU's twice as fast. Colours are now actually variables, instead of being hardcoded in the instruction like they were.
STILL haven't gotten around to making a user input/output system, though the plans exist. I can also tell you that it will have a D-pad that you can read like 2 variables: Xpad and Ypad, Though they won't actually be variables, rather functions with a save to argument. The Xpad value would be 1 if you were standing on the right arrow, -1 if you were standing on the left arrow, and 0 if you were standing on neither. I'm sure you can guess how the Ypad will work. This will make it easier to write games, paint programs, or anything using both the D-pad and GPU.
And adding GPU functions to the language. Each function should have about 4 versions, one stand alone where it will use default colour and co-ordinates already in the registers, one with coordinates, one with only colour, and one with both coordinates and colour. And functions like gpu.point1(x,y) and point2, and setColour.
No video or pictures since there's not really much new to show, sorry!
Just when I thought I fixed all local variable bugs, I find a new major one.Well, not really a bug, but rather unexpected behaviour. The assign argument function, assigning to argument 0 does not assign the first variable in a function, it actually assigns the last one with a value. Same with argument 1, assigning to the second last instead of the second. I completely forgot to test that and now that I'm trying to implement a line drawing algorithim I suddently wonder why it's not working at all.
Also, another problem: 64 ROM memory slots is way too small. It was OK for the Redgames, because coding was so tedious you never wrote complicated programs and instructions could do multiple things. Not the case here, where you can easily go over the program memory limit in minutes of writing high level code. The (untested) line drawing function I've written uses 75% of memory alone, and it's not even being called. I'll have to increase program memory size by a lot, how about 256 slots, or 3KB* of program memory?
Here's some demo programs I've written to test the compiler and faster GPU:
corridor:
Yes, it's just a big command block decoder. Basically "scoreboard players test romaddr system 2 2" for address 2, for example. Just a whole lot of those!
In other news, I've added a control room and user input! Also a new increment instruction, which is hard to explain but basically: varName+=5; used to take 3 instructions (store varname in A, store 5 in B, add A and B and store it in varname) but it's now a single instruction (add 5 to varname). This instruction can add or subtract any constant value to any variable, super useful in loops and stuff. The function can only add constants and store it at the same address it was originally in, if you want to increment by variables you need to use the ALU, but it's a whole lot faster and takes up less memory.
Compiler is working pretty well now, it's currently my main way of writing test programs. I only use assembly when debugging weird behaviour, which is occurring less than it used to. What's left now is the D-pad, arrays, some GPU framebuffer stuff (useful in saving and loading images, and basic collision detection), proper power controls, error detection (might add this after releasing and add it in a later version, not sure yet), and some documentation. There's a bit to do in the compiler as well, such as manual optimisation, some way to make arrays work, functions returning values, and some general stuff. I'd also need to document the languages...
Which reminds me, anyone have any ideas for a name for the programming language?
I've talked a lot about my high level compiler, and now I've finally made a video of it!
Boot controller is done and working, everything is going smoothly (though halting and resuming a 2 stage pipeline was a tad more difficult than I thought)
I've still got to start on documentation, making manuals and stuff though. A lot of smaller details and stuff that I don't feel like doing yet need to be done as well. I'll also be doing a video tutorial series on programming it. So, just D-pad, misc GPU stuff and other small features, along with documentation to go!
I know I'm not developing this as fast anymore, and that's because exams are coming up for me and I have other things to do. But fear not, I'm still working on this! Just not as much.
Anyway, it can now draw lines! not just vertical and horizontal lines, lines between any 2 points! (in other words, the full Bresenham's line drawing algorithm)
Along with some other features such as lighting changes on the screen, working D-pad, bugfixes, misc features...
oh yea, the GPU's gotten some updates. there's now a usable secondary framebuffer that you can use to save the state of the screen, restoring it later, and you can compare the stored and current framebuffer for some collision detection! The GPU also has 2 modes: traditional and double buffered, and can switch between them automatically or when the program wants it to.
Here's the video:
I'll make a tutorial series explaining how computers work and how they're designed (or, at least, how I design them) eventually.
an ALU is a great start. All you need to do is adress the memory, so you can send it a binary signal and a pulse on a write or read line and have it write or read to the given adress. making seperate write and read decoders might help, but it's optional.
Then, you need a block of program memory (an array of decoders with their outputs going over lines where you place redstone torches above is what I did for all my computers until this one) and make a decoder for reading the instructions, routing the arguments to the read/write lines of the RAM and/or ALU mode controls, and send a read or write pulse to whatever needs it for that command. Then advance to the next one, and you have a working computer!
If you don't want a complicated program counter and branching system, you could use the "branch on every line" system the redgames used. Makes building easier, some programs faster, but writing programs becomes a little more tedious.
In other news, I'm allowing more low level instructions to be written in the high level language so you can easily optimise your programs while still keeping the code you haven't yet optimised in high level. It could also make "porting" your program to assembly a little simpler.
And it allows you to use ALU2! Until now, the compiler routed all math to ALU1, but now...well, it still actually does that. But you can manually use ALU2 though!
Here's what the "medium level" functions look like:
is identical to:
when assembled. To use ALU2:
This allows you to keep values you use often in computations in one ALU while doing less common math in another. Or have both store X and Y coordinates or whatever. Point is, this could make stuff faster.
Talking about making stuff faster, I'm now optimising the line drawing algorithm to use both ALUs and some other tricks.
Anyway, the high level programming language's main features are done; break, continue and return are now implemented. Functions can also now return values to the calling function. The following program works now:
It prints out 11, as you would expect. It assembles to this:
Note the 2 "DS 3"s. This is Drop Stack 3, meaning leave a function and unallocate 3 local memory cells. There's 2 because the top one is the return function I called, and the other is the "normal" return that's appended at the end of every function. Clearly, this is redundant and should be removed by the optimiser later.
"COP -3 21" stores the output of the function to the temporary register (address 21 is used by my compiler for all temporary values). Then, "COP 21 23" copies it to var 23 (lol) and "DEB 23" prints out this variable. This could of course be compacted to "DEP 21", but that would be a tad to complex for the optimiser to detect. So it's not perfect, but since it can generate assembly code you can manually optimise it yourself if you know what you're doing.
ps ime still working on my GPU, mine is 64*64 pixels and runs fine even on my grandperants old windows vista 32 bit computer.
Dude you cant build a redstone computer (or any computer for that matter) unless you undedrsdand computer arckitecture.
THE MICRO$OFT APOCALYPSE IS ON!!!
32 bit redstone computer with 64*64 pixel 16 color gpu:
http://www.minecraftforum.net/forums/minecraft-discussion/redstone-discussion-and/2116999-computer-command-block-computer-now-running-with
(giant banner removed out of modesty).