OSDev.org

MIPS may be a reasonable alternative.

the article says highest i7 had 130w has well ex I was working with has tdp of ~150w/. same article here claims highest tdp in arm was 4watts. http://www.androidauthority.com/arms-se ... ng-409850/

ggodw000 wrote:I started this thread as I was vaguely interested in hearing about opinions regarding hypothetical scenario where someone seemingly enough moderate financing would enter x86 market by offering and see what the entity will encounter however the topic appears to take entirely different direction.

The problem isn't so much using a certain CPU that is documented, but the chipset and peripherals themselves. If they aren't documented and aren't standard, that's what brings troubles.

Something that everyone does is implementing emulators for other CPUs. For example you could implement a floppy-sized bootable full x86 PC emulator for x86, ARM, MIPS, etc., based in Linux along with its drivers, and run another operating system on top if it to make it look like a fully standard PC even if it is nonstandard hardware. Probably selecting only the drivers for a given machine model and peripheral combination.

Nable wrote:

~ wrote:They could use a Flash as a RAM. It's even cheaper than RAM.

You should study the subject deeply. Serial NAND flash (that is used in micro-SD and other solid-state storage) isn't random-accessible and in most tasks is awfully slow, as it provides good bulk performance but huge latency for small requests (and very huge latency for write ones). Parallel NOR flash is random-accessible but it's also slow (compared to RAM) and it's not cheap at all.

You probably perceive that MicroSD memories are extremely slow or faulty because you have used in poor ports unintended for reading them.

For example, trying to read 1-Terabyte MicroSD memories with a port that is NOT intended for SDXC.

Or also, he BenQ S6 has a MicroSD port, but it can only cleanly read memories of up to 8 Gigabytes. If you read a bigger memory, like a 16-Gigabyte memory, it will fail if you exceed certain write transfer rate speed.



Also, if you use a MicroSD memory as spare RAM for something like an x86 phone for ast system resume, capable of leaving only the phne radio turned on and the main x86 CPU without power, you will have to read/write it:

- First, without a file system, but instead as conventional RAM.

- Second, accessing it respecting its natural alignment, and also its granularity, meaning that if it needs to access in blocks of 512 or 4096 bytes (as with normal x86 paging) then we simply must do it, and the efficiency will be the best.

~ wrote:You probably perceive that MicroSD memories are extremely slow or faulty because you have used in poor ports unintended for reading them.

The fastest MicroSD cards money can buy promise 95 MB/s sequential reads and 90 MB/s sequential writes. Random-access reads are under 40 MB/s and random-access writes are under 5 MB/s.

Meanwhile, a Haswell-based PC has RAM with typical performance around 30 GB/s, read and write, random access.

No matter how you look at it, MicroSD is simply not fast enough to replace RAM.

Octocontrabass wrote:

~ wrote:You probably perceive that MicroSD memories are extremely slow or faulty because you have used in poor ports unintended for reading them.

The fastest MicroSD cards money can buy promise 95 MB/s sequential reads and 90 MB/s sequential writes. Random-access reads are under 40 MB/s and random-access writes are under 5 MB/s.

Meanwhile, a Haswell-based PC has RAM with typical performance around 30 GB/s, read and write, random access.

No matter how you look at it, MicroSD is simply not fast enough to replace RAM.

But as I said, could be useful for a portable x86 device like a phone that could be completely turned off and resumed fast to save most of the power that would otherwise be consumed, and leave only a helper circuitry that only consumed Milliwatts when in different levels of idle operation, from a HLT instruction to a full turn off.

I would personally be more than glad to get a tiny x86 which battery literally lasted weeks, like the Palm Zire m150, no matter how slow people tells me it is. If it's capable to last that much without recharging. There would be no discussion about that if it had lots of Gigabytes of RAM and several cores.

It will get better as everything else has over time, so why not? Most development tasks would be more than satisfied and covered with this.

And to play or run old software and games? It would always be incredibly fast (but could be regulated) so it's more than OK for a standardized but disposable device that would otherwise be much less interesting and useful. Just for being a tiny x86 it has a special value given by all the software that would run there, and will be more valuable as its battery reaches the duration I said before without recharging.

~ wrote:But as I said, could be useful for a portable x86 device like a phone that could be completely turned off and resumed fast to save most of the power that would otherwise be consumed, and leave only a helper circuitry that only consumed Milliwatts when in different levels of idle operation, from a HLT instruction to a full turn off.

Resuming 1GB of RAM from a MicroSD card will take 11 seconds. Resuming 16GB of RAM will take 3 minutes. This is unacceptable performance for the typical user.

~ wrote:I would personally be more than glad to get a tiny x86 which battery literally lasted weeks, like the Palm Zire m150, no matter how slow people tells me it is. If it's capable to last that much without recharging. There would be no discussion about that if it had lots of Gigabytes of RAM and several cores.

The discussion would be about the screen instead. If you want a device that is tiny and has a several-week battery life, you can't have a backlit LCD or AMOLED screen; those draw too much power. You'll need a screen more like the one on the Palm Zire m150.

~ wrote:And to play or run old software and games? It would always be incredibly fast (but could be regulated) so it's more than OK for a standardized but disposable device that would otherwise be much less interesting and useful. Just for being a tiny x86 it has a special value given by all the software that would run there, and will be more valuable as its battery reaches the duration I said before without recharging.

Having an x86 CPU does not automatically mean you can run Windows software. Having an x86 CPU does not automatically mean software will be fast. Having an x86 CPU does not automatically mean the screen will be good enough to play games (see above).

Octocontrabass wrote:

~ wrote:But as I said, could be useful for a portable x86 device like a phone that could be completely turned off and resumed fast to save most of the power that would otherwise be consumed, and leave only a helper circuitry that only consumed Milliwatts when in different levels of idle operation, from a HLT instruction to a full turn off.

Resuming 1GB of RAM from a MicroSD card will take 11 seconds. Resuming 16GB of RAM will take 3 minutes. This is unacceptable performance for the typical user.

The operating system intended for something like a phone could be optimized so that it isn't necessary to resume that much but only the strictly necessary task and system structures. Its API could be done in such a way that it stores all run-time data on disk and make it journaled so it becomes extremely robust. Then, whether it is resumed because of a crash or because of a turn off, it should always resume less than 1 GB.

The question is, why not use the exact same type of memory than the Palm Zire m150, which kept all applications in memory, its battery lasted for weeks just by pressing the ON button or sweeping the screen vertically down-to-up to turn it off, which resumed immediately when you turned it back on where you left it, and which would lose those programs not in ROM when the battery became exhausted, proving that it was indeed RAM?

Octocontrabass wrote:

~ wrote:I would personally be more than glad to get a tiny x86 which battery literally lasted weeks, like the Palm Zire m150, no matter how slow people tells me it is. If it's capable to last that much without recharging. There would be no discussion about that if it had lots of Gigabytes of RAM and several cores.

The discussion would be about the screen instead. If you want a device that is tiny and has a several-week battery life, you can't have a backlit LCD or AMOLED screen; those draw too much power. You'll need a screen more like the one on the Palm Zire m150.

~ wrote:And to play or run old software and games? It would always be incredibly fast (but could be regulated) so it's more than OK for a standardized but disposable device that would otherwise be much less interesting and useful. Just for being a tiny x86 it has a special value given by all the software that would run there, and will be more valuable as its battery reaches the duration I said before without recharging.

Having an x86 CPU does not automatically mean you can run Windows software. Having an x86 CPU does not automatically mean software will be fast. Having an x86 CPU does not automatically mean the screen will be good enough to play games (see above).

The power consumption of the CPU is still greater than that of the screen. However the latest Palms like the Palm Tungsten T|X and Palm LifeDrive only last for around 2 hours, and they use 500 MHz ARM CPUs from Intel, so it's probably the speed of the more modern processors that takes up most of the battery reserve.

I still wonder why there isn't a Linux distribution intended to implement just the absolute bare minimum, even self-compilable at the time it's installed or devices replaced, for the specific set of installed devices.

Then at that level it could implement a self-booting emulator to emulate a fully standard PC, a fully standard Android or ARM/MIPS machine.

Then it could let another Linux distribution.

If there was a Linux distribution that worked as the perfect chipset firmware that made all machines look like the same machine, then the rest of Linux distributions could become dramatically trimmed on the drivers they need, knowing that there is another layer that masks the differences with standard hardware interfaces with a protected emulator.

In this way, such Linux distribution, implementing a standard machine from any platform, would allow to run any existing operating system that regular Windows, Linux, Mac or Android can reach...

Talking in terms of operating system development, it would probably be a worthy task before thinking to write a good operating system (using the highly stable and tested Linux capabilities to implement an equally complete machine that will always look 100% standard plus future equally-standard extensions, and run our OS over that tiny Linux/bootable emulator assuming that the hardware is fully standard, even cards with hardware acceleration and all the modern capabilities).

~ wrote:The question is, why not use the exact same type of memory than the Palm Zire m150, which kept all applications in memory, its battery lasted for weeks just by pressing the ON button or sweeping the screen vertically down-to-up to turn it off, which resumed immediately when you turned it back on where you left it, and which would lose those programs not in ROM when the battery became exhausted, proving that it was indeed RAM?

You can do that, but it's worse for battery life since it must constantly use battery power in order to maintain its contents.

~ wrote:I still wonder why there isn't a Linux distribution intended to implement just the absolute bare minimum, even self-compilable at the time it's installed or devices replaced, for the specific set of installed devices.

We have that already. It's called Gentoo.

~ wrote:If there was a Linux distribution that worked as the perfect chipset firmware that made all machines look like the same machine, then the rest of Linux distributions could become dramatically trimmed on the drivers they need, knowing that there is another layer that masks the differences with standard hardware interfaces with a protected emulator.

We have that already. It's called Xen.