probably silly idea

[libber]

Hi I had a idea today when trying to get things to run on embedded platforms, since storage space is limited on this platform but there is enough ram to run useful things, it might be neat to have an os that would just bootup and take commands over the network. the idea with this is that you would have enough space to keep the current chunk of code (and other bits of code that you might jump to) and variables and of course the normal useful memory locations would be there (ports, video memeory, etc). with this setup you wouldn't need to keep much on the system itself, everything important (system calls being the first things that comes to mind) would be stored elsewhere all ready to be fed to the remote box (for ex if the remote box was intel you might have an array with 10 instructions for it ready to send, the reason for this sentence being that the stuff you were going to send the remote computer would be all ready as instructions).

The main idea here is that the only ram you would need would be the ram for the current process (plus more of course but there would be savings as i see it) and thus the remote computer which would run the stuff would have a buffer to recieve packets that have instructions in them and then every 100 instructions or so we would get rid of the code in the current buffer and get our next 100 instructions. the main usefullness of this code that i see is that if you had simple code that didn't change much at runtime (you knew what branches you were going to take or you "flattened out" the code to get rid of the branches and know every instruction that is going to be executed and in what order) you would have a simple-ish to run something on a remote box with the ram only being used for variable storage and maybe some useful functions that we call many times.

I was thinking that this could be imlimented on x86 with the use of the IF flag i think it is, to stop after each instruction and execute something else (used for debuggers). As I type this i realize you can pretty much do this by just mounting something remotely as NFS and executing what is there. anyhow its just a random idea that sounds a bit useful, i am sure there are more problems with it and that is why i am posting. anyhow this was a pretty sleep-deprived idea, but like so many of my sleep-deprived ideas i can't stop thinking about it until a massive flaw or two is pointed out to me that i didn't think of

so, any thoughts?

[Pype.Clicker]

this sound like having virtual memory over a network connexion...
The question is why trying to apply this for embedded system ? don't you think the resource required for loading part of the system over a network link in a reliable and safe way (you don't want to receive spoofed chunk of code from untrusted sources, do you) will be far above what you would download on the embedded system.

moreover, embedded system often use realtime kernels, and i don't see how you could reply to an event if parts of the kernel were to be downloaded through a network -- which is the grandest cause of random delays i've ever seen ...

so for me, either i completely miss your point, or the idea is indeed silly

[Solar]

I also don't get the notion of "limited storage space but plenty of RAM"... the PDA's I've seen so far have e.g. 32 MByte of battery-backed RAM which they split between storage and processing RAM.

By adding e.g. a CompactFlash, you increase storage space, but apps still run in the RAM. Add to this that most PDA users don't have their PDA in their (W)LAN, but rather use USB / serial based sync'ing only.

So, I don't really see where your idea comes in handy...?

[Schol-R-LEA]

If you don't mind me asking, what embedded platform(s) did you have in mind, or were you thinking in general?

It is relatively uncommon for an embedded system to use an x86 CPU other than the now-archaic 80186 (which never saw wide use in PCs). Low-end embedded systems generally use either an 8-bit processor like the 8051A or the Z8, or a 16-bit PIC, while high-end embedded systems mostly use ARM variants (StrongARM, xScale), PowerPC, or CPUs specifically designed for embedded work (Dragonball).

Even the older 32-bit chips in the x86 line (386, 486) have too high power requirements and too much heat dissipation to be practical; newer models are actually much better at power use, but heat is still a major problem. Even in full-sized x86 notebooks, which use special low-heat, low-power versions of the chips, these are major design constraints.

[libber]

I would say "vurtual memory over a network connection" is an apt description of what I am thinking of. The idea was not really meant to be useful but it was just an idea, it seems pretty straight-forward thing to impliment and if it could be done was the major part of my question. it wouldn't be used for any sort of real OS or anything. the reason that this came to mind is because I am playing around with getting stuff to work on the linksys WRT54G which has 16mb of ram for both storage and runtime and if there could be just a bootloader and very basic stuff on it and the rest of the programs could be stored somewhere else and "fed" to it over the network that would prove fairly useful. this is also why simply using an nfs module and nfs mount would be just as useful on this occasion.

Solar: Quite true and I should of specified this was very much a toy idea, just sortof wondering if it could be useful or not, and if it had been done.

My this idea sprung up after I had gotten gdbserver running on the linksys and realized that it would be kindof neat if you could store more than just a debugger "offsite" away from the cpu that it is running on.

Schol-R-LEA: I was thinking in general, the idea for using IF was just an idea I had that might work to get this idea up and running if I was so inclined at some point. I thank you for your input and am well aware that no-one uses x86 for embedded, just using the debugging facilaties of x86 seemed like a pretty reasonable thing to so assuming this was ever done for x86

so in closing, this is not a very useful idea, but I am still kind of interested in it, the best way to think of it would be like gdbserver and gdb, except OSserver and OS. just an idea

[mystran]

I'd like to add that adding a hard-drive doesn't necessarily make it less embedded. For example, there are MP3 players with a hard-drive, but you can still say they are "embedded". You can run virtual memory over a network, but even if you do, if you can afford to add a harddrive for swap space, that's probably a good idea.

Actually your 16MB memory is quite plentiful, as you can put an usable x86 Linux on two or three floppies after all, and run that with about 8MB memory and a ramdisk.

To be honest, you need 16MB ram to make it work smooth on x86, but I used to have a two floppy linux with ssh and ircII to carry around some years ago and I could irc locally and read my mail over ssh with that on 8MB machine. It just sometimes complained a lot if you tried to load too many apps into the ramdisk at the same time. Those where the happy days of good old libc4. Didn't need to use Win95 anywhere. Had ethernet modules on one of the floppies for all those cards I'd seen on the potential computers to use with that.

Anyway, I'd suggest that you make a list of what you want your embedded computer to do, then figure out how much of that you can stuff into the memory, and then see if you really need virtual memory over network. It's not very hard to make a NFS style system for that, but you'll be out of luck if you lose your network connection.

[Solar]

Actually your 16MB memory is quite plentiful, as you can put an usable x86 Linux on two or three floppies after all, and run that with about 8MB memory and a ramdisk.

Or you could take AmigaOS on a 880 kByte floppy and 512 kByte RAM. (Granted, there's a 512 kByte ROM inside an Amiga...)

Or you could take the QNX demo disk, on a 1.44 MByte floppy, booting into a Unicode-enabled GUI including web browser (dunno the memory requirements of that one).

It's funny how "two or three floppies and 8 MByte RAM" are fielded to emphasize how little space you need for an OS. (No offense intended, just remembering the good old times...)

[mystran]

It's funny how "two or three floppies and 8 MByte RAM" are fielded to emphasize how little space you need for an OS. (No offense intended, just remembering the good old times...)

My point was not to say that it was small os. My point was to say that a "big os" such as 2.0 Linux system with all kinds of apps not optimized for size, doesn't actually need as much memory as one might think.

Btw, IIRC QNX needs more memory to actually run the stuff on the demodisk.

If we want to go small with GUI, then how about the original macintosh with 128k ram and 64k rom. And most of the basic OS was on that rom after all. All the utilities, configuration data and finder were on a floppy though, along with rest of your files,
but still pretty impressive I'd say..