Yes, the unix style pipes were only for passing byte data, but there is no reason they could not be used to pass other data. A generalized pipe using hub ram could pass bytes from one application to another, addresses, values, commands, etc from one object to another. There are several ways to implement such a scheme, and it would be a good fit for a Minix style system.
In a way I have already implemented a simple pipe in spin on the P1 for getting data from an MCP3208. Any object can call the MCP object with the starting address of an array of 9 words and the object reads the 8 MCP channels and places the readings in words 1 to 8 of the array, and sets word[0] to 8. Not much to it, but it is a rudimentary pipe.
The problem I have with with piping structured types of data through pipes from one program to another is that now you cannot connect program A to program B unless both A and B agree what the structured data in the pipe should look like. You can no longer connect anything to anything unless those types line up.
You are no better off than if every program defined it's own ad hock mail box format. Pretty much as we have now.
In the "unix way" a pipe just caries bytes. You can connect anything to anything.
Of course the unix way was was concentrated on text processing. Bytes are characters, programs work on characters and can sort, filter lines, parse formats like XML, whatever you want.
Just so happened that worked very well for many other things. You can pass any old bytes, text or binary, into a compression algorithm, for example, it does not care what the format is. Or into a network socket, serial port and so on.
That's a valid point, but someone still had to make sure that the data being piped from program A to program B was compatible with program B. In the case of variables being passed between objects it would be up to the programmer or the compiler to ensure the data is in the right format for the two objects to communicate. The pipe only transfers the data.
I know what you mean. It's just not true many times.
If my program passes data to your compression program you don't need to know anything about the format of my bytes.
Or if I pass my data to a serial port or network driver.
This has proved incredibly useful over the years for many situations.
When you actually want to match up data types between programs you need a higher level abstraction layered on top of those byte streams. It leads to things like CORBA which was a dismal failure. Or passing data in XML format, another dismal failure.
That's true for data that is just a string of bytes passing from one program or device to another program or device. No reason the channel has to know anything about the format of the bytes it is passing from object A to object B either, only the two objects need to share that information.
If you were to start an experiment, a lowly Minix, for lets say the Propeller, in my case maybe using the C3 board, using C, what would be the starting point? I am not sure if anybody has done an OS here, using something like a Propeller, but I am interested in what would be the starting point?
After thinking about this some more, I came to the conclusion that porting Minix or any another OS for the Propeller is a bad idea. What it probably could use and find some benefits, is some sort of interactive program, maybe something with a scripting feature that you could use to utilize the board and the attached peripherals.
At the moment Forth is the direction that some people are heading, but not everybody is finding it useful. I guess the Propeller needs something else to choose from, something that is interactive, but has the capability to just do more than turn on/off an LED with a command.
Not sure what some thing like that would look like, but for my purposes I will use my own program, which has an interactive component, and just add other features to that. Some time ago I did do some experiments with a scripting feature, it worked, but needs lots of care and handling. The concept that keeps alluding me is, how to implement a back ground job, without fouling up the system. I guess at some point I will get there, but not today.
What is the simplest possible "background" job on a Propeller. Clearly it is 512 longs of COG program that can be started in a COG.
So what about a simple command line interface that takes commands from the user, looks for the binary blobs on an SD with the name of the command and loads that to a COG to run in the "background"?
Have some standardized mailbox or fifo interface for I/O that every such COG process adheres to allocated in HUB that any "main" program the user runs can use to interact to the COG processes.
So what about a simple command line interface that takes commands from the user, looks for the binary blobs on an SD with the name of the command and loads that to a COG to run in the "background"?
Loading cog code from SD has be done and Propeller-OSes exist.
Just a new point of view needs to be blended in there: A cogject seen as transient command as the basic block instead of being a permanently loaded driver. Communication between cogjects with a simplified SLIP-alike protocol can make cog2cog communication addressable and probably will be fit enough for prop2prop intercog communication too. Libraries can be transformed into calls to (remote) cog subfunctions...
After thinking about this some more, I came to the conclusion that porting Minix or any another OS for the Propeller is a bad idea. What it probably could use and find some benefits, is some sort of interactive program, maybe something with a scripting feature that you could use to utilize the board and the attached peripherals.
At the moment Forth is the direction that some people are heading, but not everybody is finding it useful. I guess the Propeller needs something else to choose from, something that is interactive, but has the capability to just do more than turn on/off an LED with a command.
Not sure what some thing like that would look like, but for my purposes I will use my own program, which has an interactive component, and just add other features to that. Some time ago I did do some experiments with a scripting feature, it worked, but needs lots of care and handling. The concept that keeps alluding me is, how to implement a back ground job, without fouling up the system. I guess at some point I will get there, but not today.
Ray
What you are describing sounds a lot like some of the early monitors for the 8080/Z80 that allowed one to peek, poke, fill, and jump to memory locations. One I used even had a built in assembler, although it would not resolve memory references. Something like that for the prop would not be too hard to write.
Background jobs for the prop would certainly be a lot simpler than for 8080/Z80. Just start a cog to execute the code. No task switching code required.
Comments
You are no better off than if every program defined it's own ad hock mail box format. Pretty much as we have now.
In the "unix way" a pipe just caries bytes. You can connect anything to anything.
Of course the unix way was was concentrated on text processing. Bytes are characters, programs work on characters and can sort, filter lines, parse formats like XML, whatever you want.
Just so happened that worked very well for many other things. You can pass any old bytes, text or binary, into a compression algorithm, for example, it does not care what the format is. Or into a network socket, serial port and so on.
If my program passes data to your compression program you don't need to know anything about the format of my bytes.
Or if I pass my data to a serial port or network driver.
This has proved incredibly useful over the years for many situations.
When you actually want to match up data types between programs you need a higher level abstraction layered on top of those byte streams. It leads to things like CORBA which was a dismal failure. Or passing data in XML format, another dismal failure.
Ray
Unix simply sees everything as a file.
And data transfers are either byte-by-byte or block transfers.
Not sure if pipes work with both or not.
I suspect you would have to use a shell program to pass program parameter.
If Minix follows those standards, at Unix manual will clarify much of how and why.
plan9.bell-labs.com/7thEdMan/v7vol1.pdf
At the moment Forth is the direction that some people are heading, but not everybody is finding it useful. I guess the Propeller needs something else to choose from, something that is interactive, but has the capability to just do more than turn on/off an LED with a command.
Not sure what some thing like that would look like, but for my purposes I will use my own program, which has an interactive component, and just add other features to that. Some time ago I did do some experiments with a scripting feature, it worked, but needs lots of care and handling. The concept that keeps alluding me is, how to implement a back ground job, without fouling up the system. I guess at some point I will get there, but not today.
Ray
What is the simplest possible "background" job on a Propeller. Clearly it is 512 longs of COG program that can be started in a COG.
So what about a simple command line interface that takes commands from the user, looks for the binary blobs on an SD with the name of the command and loads that to a COG to run in the "background"?
Have some standardized mailbox or fifo interface for I/O that every such COG process adheres to allocated in HUB that any "main" program the user runs can use to interact to the COG processes.
Examples (just 2 of many):
COGJECTs
SPINIX
Just a new point of view needs to be blended in there: A cogject seen as transient command as the basic block instead of being a permanently loaded driver. Communication between cogjects with a simplified SLIP-alike protocol can make cog2cog communication addressable and probably will be fit enough for prop2prop intercog communication too. Libraries can be transformed into calls to (remote) cog subfunctions...
What you are describing sounds a lot like some of the early monitors for the 8080/Z80 that allowed one to peek, poke, fill, and jump to memory locations. One I used even had a built in assembler, although it would not resolve memory references. Something like that for the prop would not be too hard to write.
Background jobs for the prop would certainly be a lot simpler than for 8080/Z80. Just start a cog to execute the code. No task switching code required.