Project V: Multiple Output

Monday, 8. October 2007, 03:44:37

I just created my first component that outputs two values. The division component. It's all UInt32 right now. I'll make more abstract versions later. Anyways, the inputs are the dividend and the divisor. And the outputs are the quotient and the remainder. ROCK ON!

That's all I have to say. Maybe someone in the future will find this an interesting bit of trivia.

Now, onto the runtime engine to see if all this work actually does something. I may do this tomorrow or the day after. I'll only add threading and multiple machines later as well. So another week or so to get a full concurrent version going. But I'm like *this close* (ok, so you can't see the space between my finger and thumb) to getting a running version.

OH, this is a stupid question, but ummm... should I implement more stuff that can work on UInt32? I have addition, subtraction, multiplication and division right now. Man, I've been so involved with this, I've forgotten basic math. OH!!! Conditionals. Damn! That's the ticket. It ain't Turing complete yet. Ok, I'll put those in. Ah booleans would be nice too. Hmmmm.... ok. And, Or, Not. Xor. Anything else? List them here. I only want basic stuff related to Turing complete and UInt32. Maybe some shift operations? Ok, I'll add those too. Rotate? A bit much perhaps. Print component to see some results. I'll hardcode the inputs for now inside custom components. I'll add these things right now.

So consider this a feature request. What low level tools do you want or am I missing?

Wasted PowerProject V: Dealing With Components

Comments

I just have one question for now---how do you handle division by zero?

By spc476, # 8. October 2007, 06:03:15

It shouldn't come to this component at all, I think. The division by zero (output check) must be handled within the previous component.

By vladas, # 8. October 2007, 11:23:13

I think these two low-level thingies can be added too: memset and memmove. Regarding memcmp - you'd have been added these within common comparatios.

By vladas, # 8. October 2007, 11:39:02

Division by zero is not handled. These are low level components. Later, there will be "safe" components that you can use. For example, multiply will also give an error if it's out of range. It's part of error outputs and will be handled differently. I'm only implementing these further on though.

memset and memcmp are a little too low level. Besides, you can create generators as well as compare streams quite easily with the compare components.

By Vorlath, # 8. October 2007, 19:20:07

Kyle Lahnakoski writes:

What do you mean by "conditionals"? Do you mean logical operators or the ability to branch in your code?

I suggest an exercise in mapping from a known language to your system's, and back. That will help reveal your system's shortcomings. Like divide-by-zero shows a need for a "safe" layer.

I tried to map JVM code to my system, and the jump-to-subroutine instruction revealed complexity I did not consider.

By anonymous user, # 17. October 2007, 10:49:23

Conditionals are the ability to do something on one of the inputs depending on a selector. For example, I can select one of the input items and move it to the single output. Or I can redirect the input item to one of the many outputs. In the hardware world, this is called a multiplexor and demultiplexor. But that sounds scary. One is actually just a sequencer (ordering many streams into one) and the other is a redirection filter (being able to split a stream into many).

Mapping to an existing language is kinda hard to do considering that Project V is a different fundamental concept of computing than what programming languages typically use. Take functions. There are no functions in Project V. While I can accomplish the equivalent computationally, I must end up removing the concept of the function entirely. It's a destructive conversion. So this serves no purpose for me. Jumps of any kind are also destructive conversions. In addition to implying functions, it also includes any jumps to code blocks. So no 'if', 'while', 'for', 'switch', 'do', 'break', 'continue', 'return', 'else', 'goto', 'catch', 'try' and 'throw'. Along with functions, these are all things that manipulate the hardware program counter... making these useless in a dataflow environment. Oh, throw in threads in that list while we're at it.

Other than primitive operations (which I have), what's left?

By Vorlath, # 17. October 2007, 17:48:16

Kyle Lahnakoski writes:

Certainly, you must leverage existing code to get any decent distance with your idea. Even if existing code manipulates the instruction pointer, you will have to convert it to your system's form, even if it is inefficient. This will turn a programming task into an API design effort; which is considerably easier.

Some things that I think "are left" for you to do probably in the domain where Haskell requires monads: performing side effects. How is a simple database (aka tab delimited list of objects, or other object store) implemented? Can you make a simple JSP server? If not, what replaces similar functionality?

How do you solve some of the classic threading problems, like the dining philosophers? What does the solution look like, and what replaces the need for locks?

By anonymous user, # 20. October 2007, 01:49:32

I'm implementing an API for access to old code. That's how primitive components work for now until I write the compiler. Well, I'm using built-in functions but there'll be a way to use your own functions if you want.

I already have a system in place for components that have side-effects. You can have attached components that share data. They're basically a single component that is displayed separately (and often differently). These can actually be pure internally in some cases.

Dining philosophers is a problem based on workers (threads). Obviously, if you're constrained to using threads, you have to deal with it. That's why I cannot offer solutions where humans are the actors such as what happens on a wiki. But this isn't classic threading because the philosophers aren't allowed to talk to each other.

Oh, you asked about JSP. I'm assuming you want to know about sessions and such. You can use humans as components. This is a very important concept not found in ANY other development environment. So your server can be thought of one big component and so can the human. The output of the server is linked to the input of the human and the output of the human is linked to the input of the server. Note that your server can have other outputs because there's no limit to how many inputs and outputs you can have.

You can then connect parts of your web site in a manner where the user must go to a select choice of further pages. Page1->User->Page2->User->Checkout sort of deal. Here, we use the concept I mentioned before where the User component is attached. It's located in two different places, but is actually the same user. Or you can set it up to leave pages open accessible at any time. Or you can specify that certain pages can only come from certain other pages. You can set up any rules you like.

If you want an example for locks... the primary advantage is that everything that can be pipelined will be parallel without any locks. So if you use the same operation on many items (ever write a loop? or do many operations on a sequence of data?), then that will be parallel automatically. It'll take care of any dependencies for you. Will it lock at the low level? Sure, but it's dynamic locking. It'll adapt to what you're doing and will group things together to minimize the number of locks. And there are ways to use atomic compare and exchange instructions to speed things up when locking is necessary. There are even cases where locking won't be needed between processors.

By Vorlath, # 21. October 2007, 05:38:36