affordable ARM hardware/sbc for OS dev?

[Michael Unrest Lenz]

Good morning,

first of all I have to admit that I want to (re)invent the wheel - i.e. I
want to develop a (simple, monolithic) operating system on expandable
hardware - be it an sbc with USB, Networking etc. or a micrcontroller
evaluation board with loads of GPIO pins.

I want it to be an ARM architecture, cause it's sleek and not bloated/
ugly like x86.

It must have a MMU as I want virtual memory without the hassle of load-
time binary patching.

As I am a poor student such a hardware *must* be relatively cheap (read:
<50EUR) and available of course. I thought of getting myself a
RaspberryPi, but... You know..

Is there any hardware you can recommend?


Yours,
Michael

PS: Please excuse my partially glitchy English - it's early morning here
in Germany. ;)

[Nomen Nescio]

Hallo Michael

There was discussion on this topic of raspberry pi in many newsgroups. I
read you maybe can't make your own OS easily on this board because of, some
binary blob but you should check. Yes like you I hope to find a cheap SBC
but everything is very expensive sometimes even more than a new PC. You can
find evaluation boards from 200 EURO and above even to 500 EURO. Complete
madness for small guy....... stop the insanity please ppl

[BGB]

or, for testing, there is also QEMU.

it isn't fast, or real HW, but it runs on PCs and is free.



I will disagree with the OP though for asserting that ARM is less ugly
than x86.

IMHO, at the level of the ISA, ARM is considerably more ugly, and far
less internally consistent, than is the x86 ISA.

for example, at least x86 has fairly consistent instruction encoding
rules. for ARM, instruction layout varies from one instruction to the
next (many operands are irregularly-placed bit-fields), and based on
whether it is 32-bit ARM instructions, or Thumb / Thumb-2 instructions,
or Jazelle / ThumbEE, as well as for whether certain ISA features are
available or not (depends on both mode and ISA version), ...

on x86, it is also fairly trivial to get an immediate loaded into a
register, but on ARM it is far less trivial (the assembler may in-fact
emit a long instruction chain and/or load from memory).

likewise, call and jump instructions may require several instruction
words, ... (and be longer than their x86 equivalents).

...


not that x86 is by any means perfect though.

a lot may depend though on what one is measuring things by.

ARM has an advantage related to small die size and power use, but I will
contend that being "clean" or "elegant" are not merits for the architecture.

much of the large die-size and power-use of x86 is more due to getting
high performance (lots of cache, multiple ALUs and FPUs, execution
pipelines, ...), and not because the architecture is inherently messy or
complicated.

a streamlined 386-like core with low power use would be very possible,
it just would not be performance-competitive with current chips.


likewise for ARM:
some current designs actually have the ARM-chip being dual-core (the
"big-little architecture"), with a "big" core (higher-performance, ...)
and a "little" core (small, low power use, ...) and switching between
them based on CPU load.

similar could probably also be done with x86.


or such...

[Fritz Wuehler]

> I will disagree with the OP though for asserting that ARM is less ugly
> than x86.

I will take your word for it but I must agree with the OP x86 is ugly, so
ugly I can't believe it.

Is there any common microprocessor that has a nice architecture?

[James Harris]

On Apr 20, 5:19 am, Fritz Wuehler

What is it you find ugly about x86?

James

[Single Stage to Orbit]

On Fri, 2012-04-20 at 06:19 +0200, Fritz Wuehler wrote:
> Is there any common microprocessor that has a nice architecture?

Motorola 68x00 had an extremely elegant instruction set but only the
Coldfire's used in embedded applications nowadays.
--
Tactical Nuclear Kittens

[Fritz Wuehler]

Yes you have right I have used when they were new the 6809 and its easy
architecture to work with it. But now I dont find something so nice in
microprocessor and I play bit with FPGA design of my own..I think Intel
destroy computers for everyone

[van...@vsta.org]

Fritz Wuehler <fr...@spamexpire-201204.rodent.frell.theremailer.net> wrote:
> Is there any common microprocessor that has a nice architecture?

MIPS is the nicest I've ever worked with, FWIW. Instruction set, protection
model, thoughtful accomodations for bootup and/or running embedded, and just
the right set of primitives to let you construct the kind of interrupt,
exception, and page fault handling you desire. If your CPU has 64 bit
support, it also has the nicest backward integration of 64-bit data types
into the original 32-bit architecture.

--
Andy Valencia
Home page: http://www.vsta.org/andy/
To contact me: http://www.vsta.org/contact/andy.html

[van...@vsta.org]

Single Stage to Orbit <alex....@munted.eu> wrote:
>> Is there any common microprocessor that has a nice architecture?
> Motorola 68x00 had an extremely elegant instruction set but only the
> Coldfire's used in embedded applications nowadays.

Moto always was a mess on the OS side, though. You had to jump through all
sorts of hoops to correctly field exceptions, implement virtual memory, or
get SMP working. And they considered the OS side to be per-model, so each
new generation had its own unique blend of demands on the OS dev. Say what
you will about the x86 ISA, at least they considered the system mechanisms to
also be part of the hardware API, and have done quite a good job of
not gratuitously forcing the OS to chase the CPU.

Oh, and Moto *never* got their head all the way around SMP. By the time I
got to Sequent and was doing kernel work for their x86 SMP systems, I think
nobody was left who believed Moto would ever supply a sane starting point for
a scalable SMP system.

[Antoine Leca]

Fritz Wuehler wrote:
> Single Stage to Orbit <alex....@munted.eu> wrote:
>> Motorola 68x00 had an extremely elegant instruction set but only the
>> Coldfire's used in embedded applications nowadays.
>

> Yes you have right I have used when they were new the 6809

6809 ('77 8-bit CPU with one 16-bit data and 3+1 16-bit address
registers) or 68000 ('80 8 32-bit data and 8+1 32-bit addr.registers)?

> I think Intel destroy computers for everyone

You might want to have a look at 8051


Antoine

[Single Stage to Orbit]

I'm inclined to agree, I've never seen a 68k multiprocessor system, too
hard to do, I guess.
--
Tactical Nuclear Kittens

[van...@vsta.org]

Single Stage to Orbit <alex....@munted.eu> wrote:
> I'm inclined to agree, I've never seen a 68k multiprocessor system, too
> hard to do, I guess.

The 68040 was the closest I got, but it turned out that Moto had
underestimated the complexity of cache coherence, and the '040 ended up
having to interlock too much CPU state too much of the time as it got cache
state updates off the bus. Didn't scale at all.

[BGB]

On 4/19/2012 9:19 PM, Fritz Wuehler wrote:
>> I will disagree with the OP though for asserting that ARM is less ugly
>> than x86.
>
> I will take your word for it but I must agree with the OP x86 is ugly, so
> ugly I can't believe it.
>

I before thought x86 was fairly ugly, but then looked at ARM, and was
surprised at how messy the ISA was.

IMO, what seems most "ugly" personally is most of the OS-level and
legacy cruft, whereas if x86 were defined solely/primarily in terms of
what is visible from userspace, it would be less so.


instruction layout could be better, but I haven't personally found any
"significantly better" ways to handle things, such as "Mod/RM"
encodings, short of making the average-case instructions longer.

yes, granted, the "use a pile of prefixes" strategy for adding opcodes
also sucks. better could be a simpler "variable-length" encoding and
probably eliminating most of the prefixes.


in my own bytecode formats, this is typically used:
0x00..0xBF: single-byte opcodes (192 opcodes)
0xC0..0xEF: 2-byte opcodes (12288 opcodes)
0xF0..0xFF: 3-byte and longer (limit is a 5-byte form with 4G opcodes).

as-is, likely the entire current x86 ISA would fit in the 2-byte range.

also possible:
0x00..0xEF: single byte (240 opcodes)
0xF0..0xFE: 2-byte opcodes (3840 opcodes)
0xFF: 4-byte opcodes (16M opcodes)


more complex is the matter of encoding the Mod/RM byte, where the
"simple case" would result in needing 2 bytes for the suffix (with 16
registers), although, it would be possible to split some opcodes by
memory layout and size (and just "eat the cost" for instructions which
access memory).

so, example instruction forms (16 regs, say R0-R15):
mov reg, reg (2 byte, xxxxxxxx ddddssss)
mov reg8/16/32/64, [mem] (3+ byte, xxxxxxxx mmttdddd bbbbiiii +)
mov [mem], reg8/16/32/64 (3+ byte, xxxxxxxx mmttdddd bbbbiiii +)
mov reg, imm12 (3 byte, xxxxxxxx ddddiiii iiiiiiii)
...

say, for example (Mod/RM analogue):
mm=0: [reg+imm4] (signed 4-bit scaled offset)
mm=1: [reg+idx]
mm=2: [reg+idx+imm8]
mm=3: [reg+idx+imm32]
tt=0: 8-bit ops, scale=1
tt=1: 16-bit ops, scale=2
tt=2: 32-bit ops, scale=4
tt=3: 64-bit ops, scale=8

tt could be 32/64/128/256 for FPU/SIMD ops.

possibly with a "shadow register" (say, R15) which can't be used as a
base or index:
if used as an index, it indicates that no index is used;
if used as a base, it serves as an IP/PC alias (for relative addressing).

...

unclear would be whether calls/returns would be better via the stack or
a "link register" (maybe R15==LR).

also unclear if it would be better to use unified or separate registers
for integer/pointer and FPU/SIMD.

> Is there any common microprocessor that has a nice architecture?
>

not that I am aware of.


someone else mentioned MIPS, which seemed fairly sensible:
IIRC, fixed-width word-based ISA with a reasonably consistent
instruction layout, ...

however, whether or not MIPS is "common" is debatable.

besides x86 and ARM, there is PPC, but I haven't really looked as much
into PPC.


or such...

[Single Stage to Orbit]

On Fri, 2012-04-20 at 14:28 -0700, BGB wrote:
> omeone else mentioned MIPS, which seemed fairly sensible:
> IIRC, fixed-width word-based ISA with a reasonably consistent
> instruction layout, ...
>
> however, whether or not MIPS is "common" is debatable.

It's quite common; in fact I have an old wireless-G router and a newer
wireless-N router that both are MIPS-based SOCs (System On Chip). Very
nice machines!
--
Tactical Nuclear Kittens

[BGB]

this still doesn't mean it is necessarily all that "common", at least if
compared with x86, ARM, and PPC, only that it is not entirely uncommon
either.

[Fritz Wuehler]

van...@vsta.org wrote:

> Fritz Wuehler <fr...@spamexpire-201204.rodent.frell.theremailer.net> wrote:
> > Is there any common microprocessor that has a nice architecture?
>
> MIPS is the nicest I've ever worked with, FWIW. Instruction set, protection
> model, thoughtful accomodations for bootup and/or running embedded, and just
> the right set of primitives to let you construct the kind of interrupt,
> exception, and page fault handling you desire. If your CPU has 64 bit
> support, it also has the nicest backward integration of 64-bit data types
> into the original 32-bit architecture.

MIPS looks ok but the 3 address arch is hard to get used to. Are there any
SBC based on MIPS? The Longsoon stuff is way expensive for what you get. And
what OS is available for MIPS besides (barf) Linux?

[Scott Wood]

There was this thing called "powerpc" that came after, though...

-Scott

[Scott Wood]

On 2012-04-19, BGB <cr8...@hotmail.com> wrote:
> I will disagree with the OP though for asserting that ARM is less ugly
> than x86.
>
> IMHO, at the level of the ISA, ARM is considerably more ugly, and far
> less internally consistent, than is the x86 ISA.
>
> for example, at least x86 has fairly consistent instruction encoding
> rules. for ARM, instruction layout varies from one instruction to the
> next (many operands are irregularly-placed bit-fields), and based on
> whether it is 32-bit ARM instructions, or Thumb / Thumb-2 instructions,
> or Jazelle / ThumbEE, as well as for whether certain ISA features are
> available or not (depends on both mode and ISA version), ...

x86 doesn't have instruction set extensions that must be tested for?

> on x86, it is also fairly trivial to get an immediate loaded into a
> register, but on ARM it is far less trivial (the assembler may in-fact
> emit a long instruction chain and/or load from memory).

That's the price you pay for fixed-length (and reasonable-length)
instructions. It's more or less the same on any RISC, though some (like
ARM) may need longer instruction chains than others (when not loading from
memory), due to the smaller immediate value size.

> likewise, call and jump instructions may require several instruction
> words, ... (and be longer than their x86 equivalents).

Do you have benchmarks to show that this is a serious problem?

> not that x86 is by any means perfect though.

Indeed.

> ARM has an advantage related to small die size and power use, but I will
> contend that being "clean" or "elegant" are not merits for the architecture.

It's not the cleanest RISC I've seen (Alpha or MIPS would probably have to
take the prize there), but it's cleaner than x86.

> much of the large die-size and power-use of x86 is more due to getting
> high performance (lots of cache, multiple ALUs and FPUs, execution
> pipelines, ...), and not because the architecture is inherently messy or
> complicated.

Sure, but it wouldn't hurt (other than compatibility) if the architecture
were cleaner.

-Scott

[Single Stage to Orbit]

On Mon, 2012-04-23 at 01:06 -0500, Scott Wood wrote:
> > I'm inclined to agree, I've never seen a 68k multiprocessor system,
> too
> > hard to do, I guess.
>
> There was this thing called "powerpc" that came after, though...

At least PowerPC's SMP capable. There's been dual/quad SMP PPC boxes out
there.
--
Tactical Nuclear Kittens

[BGB]

On 4/22/2012 11:19 PM, Scott Wood wrote:
> On 2012-04-19, BGB<cr8...@hotmail.com> wrote:
>> I will disagree with the OP though for asserting that ARM is less ugly
>> than x86.
>>
>> IMHO, at the level of the ISA, ARM is considerably more ugly, and far
>> less internally consistent, than is the x86 ISA.
>>
>> for example, at least x86 has fairly consistent instruction encoding
>> rules. for ARM, instruction layout varies from one instruction to the
>> next (many operands are irregularly-placed bit-fields), and based on
>> whether it is 32-bit ARM instructions, or Thumb / Thumb-2 instructions,
>> or Jazelle / ThumbEE, as well as for whether certain ISA features are
>> available or not (depends on both mode and ISA version), ...
>
> x86 doesn't have instruction set extensions that must be tested for?
>

there are differences:
most extensions don't dramatically change the way the basic ISA works;
usually, after a while certain features become "standard" and are
present on all later CPUs (for example, the present state of SSE and
SSE2, ...), and thus no longer need testing.

likewise, nearly all are either available or not available, so it is
more about checking CPUID bits.

>> on x86, it is also fairly trivial to get an immediate loaded into a
>> register, but on ARM it is far less trivial (the assembler may in-fact
>> emit a long instruction chain and/or load from memory).
>
> That's the price you pay for fixed-length (and reasonable-length)
> instructions. It's more or less the same on any RISC, though some (like
> ARM) may need longer instruction chains than others (when not loading from
> memory), due to the smaller immediate value size.
>

it *can* be done better, including with fixed-width.

also, Thumb is arguably variable-width, given that instructions may
require a variable number of 16-bit words.

>> likewise, call and jump instructions may require several instruction
>> words, ... (and be longer than their x86 equivalents).
>
> Do you have benchmarks to show that this is a serious problem?
>

it does waste memory and adds complexity to writing assemblers and
linkers. it is no longer possible to simply perform a relocation on a
word, now the linker has to take things like the instruction encoding
into account.

as for cleanliness / elegance aspects of the ISA, consistent instruction
coding is much more important than performance, which was what all this
was about.

>> not that x86 is by any means perfect though.
>
> Indeed.
>
>> ARM has an advantage related to small die size and power use, but I will
>> contend that being "clean" or "elegant" are not merits for the architecture.
>
> It's not the cleanest RISC I've seen (Alpha or MIPS would probably have to
> take the prize there), but it's cleaner than x86.
>

I will disagree that it is cleaner than x86.
IMO, it is much uglier, especially in the case of Thumb/Thumb2/ThumbEE
modes.

I am not complaining so much here about RISCs in general, but rather the
specifics of ARM.

if everything were the 32-bit ARM instructions, I would not be
complaining so much, except that many use cases of ARM, such as
targeting Android, generally use Thumb code.


a big issue with thumb is that nearly every opcode has its own layout,
rather than:
most other RISCs, which have only one of several instruction forms;
x86, which (effectively) has one of several basic instruction forms.


how much variability is in x86 normally?:
<op>|r op reg
<op>|r,i op reg, imm
<op>/r op reg, mem / op mem, reg
<op>/r,i op reg, mem, imm / op mem, reg, imm
<op>/0-7 op mem
<op>/0-7,i op mem, imm

for the most part, this is fairly consistently applied across the entire
ISA, with few exceptions.


in ARM, and especially in Thumb/Thumb2, most values are placed into
bit-fields, with little regularity as to where in the instruction word
the value is placed. this makes instruction encoding much more complex.


IMO, the only thing "particularly" ugly about x86 instruction encoding
is the abuse of prefixes common in composing many opcodes.

but, if the prefixes are simply treated as fixed byte patterns or escape
codes, it is no longer really a significant issue.

>> much of the large die-size and power-use of x86 is more due to getting
>> high performance (lots of cache, multiple ALUs and FPUs, execution
>> pipelines, ...), and not because the architecture is inherently messy or
>> complicated.
>
> Sure, but it wouldn't hurt (other than compatibility) if the architecture
> were cleaner.
>

the issue could be partly that of "strict" compatibility, vs "relative"
compatibility.

for example:
what if the CPU removed real-mode and legacy PMode (IOW: CPU only has
Long-Mode and 32-bit Compatibility Mode) ?...
...

the CPU would no longer be strictly compatible (and would some OS
support), but from the level of applications it wouldn't necessarily
look all that much different.

[van...@vsta.org]

Fritz Wuehler <fr...@spamexpire-201204.rodent.frell.theremailer.net> wrote:
> MIPS looks ok but the 3 address arch is hard to get used to. Are there any
> SBC based on MIPS? The Longsoon stuff is way expensive for what you get.

While not an SBC, I believe the nanonote is based on a MIPS type of CPU. $94
via Amazon.

> And what OS is available for MIPS besides (barf) Linux?

QNX Neutrino has gone open source and has MIPS support.

[Fritz Wuehler]

Scott Wood <sc...@buserror.net> wrote:

> There was this thing called "powerpc" that came after, though...

Right but it has nothing to do with 68K so...

[Single Stage to Orbit]

On Mon, 2012-04-23 at 16:49 +0000, van...@vsta.org wrote:
> Fritz Wuehler <fr...@spamexpire-201204.rodent.frell.theremailer.net>
> wrote:
> > MIPS looks ok but the 3 address arch is hard to get used to. Are
> there any
> > SBC based on MIPS? The Longsoon stuff is way expensive for what you
> get.
>
> While not an SBC, I believe the nanonote is based on a MIPS type of
> CPU. $94 via Amazon.

Looks very cute but quite useless for serious computing :)
--
Tactical Nuclear Kittens

[Fritz Wuehler]

thanks friend

[Scott Wood]

I was responding to "Moto *never* got their head all the way around SMP".

-Scott

[Fritz Wuehler]

But PPC does have SMP support. Are you complaining about Motorola's OS (was
there one) or Motorola chips?

[van...@vsta.org]

Scott Wood <sc...@buserror.net> wrote:
> I was responding to "Moto *never* got their head all the way around SMP".

Quite right! My comment was intended solely WRT 68k. I have no experience
with Moto CPU's post-68k. My statement was thus overly broad.

[Lucretia]

On Sunday, April 22, 2012 9:26:18 PM UTC+1, Fritz Wuehler wrote:

>
> MIPS looks ok but the 3 address arch is hard to get used to. Are there any
> SBC based on MIPS? The Longsoon stuff is way expensive for what you get. And
> what OS is available for MIPS besides (barf) Linux?

There is the ChipKIT Uno32 (Arduino profile) board which has a PIC32 on it, which is MIPS. A larger MIPS machine to look at would be an SGI one.

Luke.

[Lucretia]

On Monday, April 23, 2012 5:49:41 PM UTC+1, (unknown) wrote:

> > And what OS is available for MIPS besides (barf) Linux?
>
> QNX Neutrino has gone open source and has MIPS support.

QNX has not been OSS for years now.

Luke.

[van...@vsta.org]

Lucretia <lague...@googlemail.com> wrote:
>> > And what OS is available for MIPS besides (barf) Linux?
>> QNX Neutrino has gone open source and has MIPS support.
> QNX has not been OSS for years now.

Wow, hadn't heard about that. Glad I have a snapshot....