Subject: Re ELF

From: Charles Esson <[email-masked]>
Date: Wed, 02 Jul 1997 10:51:18 +1000

Could I please ask a few questions.

1) Does anyone know where one gets the ELF standard.

2) I could be barking up the wrong tree but: 
a) The strong ARM cache uses virtual addresses. 
b) To flush the write cache we have to read data from an uncached area,
16k of it.

I don't think a task switch should involve cleaning up a 16k cache, if
it does performance will be pretty poor.

If we map all processes into one virtual address space and under no
circumstances we map physical space into the virtual space twice then
the cache will never have to be flushed. This I see as a must.

Can any one see why this can't be done with ELF?

Regards

---

From: Matthew Wilcox <[email-masked]>
Date: Wed, 2 Jul 1997 18:51:16 +0100 (BST)

> 1) Does anyone know where one gets the ELF standard.

No.  Sorry.  Try a web search in altavista.

> b) To flush the write cache we have to read data from an uncached area,

No.  To flush the instruction and data cache, the recommended method is to
read 32kB.  

> it does performance will be pretty poor.

It isn't /that/ bad.  Other CPUs manage that, and considerably worse.  The
problem is exacerbated by the RPCs slow memory bus, but it's still
liveable with and it's considerably better than your alternative
suggestion.

> the cache will never have to be flushed. This I see as a must.

This I see as a very bad idea.  It would mean all sorts of stupid
restrictions on applications that don't exist under any other
architecture.  You'd be limited to about 64MB per application and 48 tasks
running simultaneously.  This is crap.

---

From: "Neil A. Carson" <[email-masked]>
Date: Wed, 02 Jul 1997 20:19:04 +0100 (BST)

> No.  To flush the instruction and data cache, the recommended method is to

No, only if you're silly. If you're clever, you only do 16Kb.

> liveable with and it's considerably better than your alternative

I diasgree. Not many CPUs need to do this and considerably worse, I can't
think of any mainstream ones to hand...

> running simultaneously.  This is crap.

No, that is crap :-) Why are you limited to this?

	Neil

-- 
Neil A. Carson
Marketing Director              Causality Limited (London, UK)
Tel/Fax: +44 (0)181 930 7408    Mobile: +44 (0)370 593183
Email: [email-masked]       WWW: http://www.causality.com.

---

From: Charles Esson <[email-masked]>
Date: Wed, 02 Jul 1997 20:45:44 +1000

> No.  Sorry.  Try a web search in altavista.

I have tried, I found out a lot about garden decoration. I remember
reading somewhere that the sunsite has it. I will try there ( and search
again).

> liveable with and it's considerably better than your alternative
I think a lot of architectures cache after the MMU. The 68040, the only
other MMU I have spent time pondering, caches physical addresses.

Unfortunatly enginering is about trade offs. The biggest problem I see
is the stack space, this is a block of memory that can grow. If you have
a complete virtual address space for the task  you can place the stack
in the middle of a very large empty address space and let it do what it
wants. If all the tasks have to run in one vitual space there would have
to be some restriction.
But this would be better than being limited to the physical space ( see
OS9 as a unix derivative that does this). I can't see a reason to place
restrictions on a tasks size or the number of tasks. I can see there is
a risk that you would not be able to load a task because of memory
fragmentation, but I think this is in the same category as " You are
running out of paging file". An error you see and fix by closng a few
applications.

I think it's horses for courses. The strong Arms stength is low power,
and a core that flies.
It's disadvantages are, no FPU, cache controllers that work in the
virtual address space and to be honest bus bandwidth that makes the
cache controllers and write back buffer a must, if the core is going to
be kept busy ( no doubt I will find others as time goes on).

The strong arm is perfect for compute intensive real time work. I cannot
see it being the processor of choice for a general purpose PC. As much
as I dislike the intel instruction set
it would be a better choice for that application.

The instruction set is another reason to pick the ARM for real time
work, an irrelevent consideration if you are going to write everything
is C, if you are using the system for real time work there is a risk
that assembler will be used. The ARM has a really nice instruction set
and like the 68k I can see assembler code being a viable choice.

The marketing and the architecture of the ARM is aimed directly at the
real time market. There is a real need for a freely available real time
operating system. Perhaps it would be best if the linux ARM port made
trade offs that made it more suitable for the market the ARM is aimed
for.

One thing is for sure that is where my efforts will go, because this is
what I need.

---

From: Manar Hussain <[email-masked]>
Date: Thu, 3 Jul 1997 08:48:03 +0100 (BST)

>reading somewhere that the sunsite has it. I will try there ( and search

I'd try at the linux.org pages first ...

Manar

---

From: Matthew Wilcox <[email-masked]>
Date: Thu, 3 Jul 1997 09:12:21 +0100 (BST)

> No, only if you're silly. If you're clever, you only do 16Kb.

I misremembered DECs recommendation then.  Sorry.

> think of any mainstream ones to hand...

Other CPUs have to /effectively/ do this (ie flush the caches on a context
switch).  It's just that on the ARM, you have to do this yourself.  I was
basing the 'considerably worse' on the fact that other CPUs have large L1
caches.

> No, that is crap :-) Why are you limited to this?

Cos 64MB * 48 = 3GB.  I was assuming the top GB would be reserved for
various bits of iffiness like kernel workspace and mapping devices into
and so on.  I suppose you could always do the Minix Thang and get each
binary to declare how much space it required and get more tasks in that
way, but then you end up with fragmented address spaces and all sorts of
horrible things.  Or you could maybe trade off a little - 96 tasks each
with 32MB.  The point I'm making is that it's a Very Bad Idea for a
general purpose Unix system.  As Charles Esson said, it's probably okay
for some limited purpose realtime system, but the Linux kernel is not a
realtime system.  Unless you run it on top of Mach, of course... ;-)

---

From: Alan Cox <[email-masked]>
Date: Thu, 3 Jul 1997 09:37:00 +0100 (BST)

> think of any mainstream ones to hand...

It is an extremely poor piece of design. The last thing you need to do on
a modern machine is load your bus down reading crap because the processor
lacks a very basic cache flush operation.

On the P5 its about 10 clocks to flush the cache and no bus activity

Alan

---

From: Alan Cox <[email-masked]>
Date: Thu, 3 Jul 1997 10:09:33 +0100 (BST)

> basing the 'considerably worse' on the fact that other CPUs have large L1

Physically cached CPU's dont have to flush the cache on a context switch.
Intel CPU's throw out the 17 entry TLB if the page tables for the different
tasks are not the same, but not cache. 

The older sun4 cpu's do need to flush caches on some switches but they have
tags on the cache lines so you can avoid flushes when flipping between 
the most currently run tasks (number running is rarely over 8 or 16)

Alan

---

From: "Neil A. Carson" <[email-masked]>
Date: Thu, 03 Jul 1997 10:03:57 +0100 (BST)

> I misremembered DECs recommendation then.  Sorry.

This is the noddy way of doing things. For example Digital's own code in their
NC only uses 16kb :-) Maybe they've forgotten!!

> basing the 'considerably worse' on the fact that other CPUs have large L1

No, they don't. Other processors cache by physical address, not by virtual
address. So when memory is remapped they do not need to reflush. Some can
also have memory-coherent caches, so even if you DMA in you still don't
need to do a cache flush even if multiple CPUs are present (see the BeBox
for example). The ARM caches by virtual address; this allows the MMU to run
slower (and thus use less power) and also removes some extra logic.

> Cos 64MB * 48 = 3GB.  I was assuming the top GB would be reserved for

But so what? Why should you have to have a fixed size for every process?

> horrible things.  Or you could maybe trade off a little - 96 tasks each

No. I agree with you it's nice a nice idea - but why would you have to do
this? Allocate 1meg for each descending stack. You now how big a processes
text area is so you only allocate it that for code. Data are is initially
of a known size, and you could redirect calls to memory allocation to use
somewhere else in the memory map.

	Neil

---

From: "Neil A. Carson" <[email-masked]>
Date: Thu, 03 Jul 1997 10:03:57 +0100 (BST)

Neil

---

From: Philip Blundell <[email-masked]>
Date: Thu, 3 Jul 1997 12:23:34 +0100 (BST)

> No.  Sorry.  Try a web search in altavista.

The Solaris documentation is the nearest thing to a standard.

p.

---

From: "Ka'Plaagh" <[email-masked]>
Date: Thu, 03 Jul 1997 15:41:32 +0000

> No, only if you're silly. If you're clever, you only do 16Kb.

True.  Also you can flush the I cache with 1 instruction, you only clean D-cache.
To clean it you need to map a lump of memory to a high virtual address (the 
cache is virtually-tagged) and then read enough to evict all of the cache's
previous contents.   The 21285 (aka Footbridge) support chip makes this easy
by having an area of memory that does not actually exist, read cycles complete
in no time and return 0.  This is precisely to make cleaning the D-Cache quicker.

> No, that is crap :-) Why are you limited to this?

----------------------------------------------------------------------
David A Rusling				Principal Engineer
European Semiconductor Applications	Digital Equipment Co Ltd.,
	Engineering			PO Box 121,
					Imperial Way,
					Worton Grange
					Reading RG2 0TU
Linux, Alpha, StrongArm, PCI		Tel: UK-(0)1734-204380
					Fax: UK-(0)1734-203133
----------------------------------------------------------------------

---

From: "Ka'Plaagh" <[email-masked]>
Date: Thu, 03 Jul 1997 17:39:45 +0000

> On the P5 its about 10 clocks to flush the cache and no bus activity

I tend to agree, when I started looking at (Strong)ARM after Alpha I 
did not like the MMU at all.  Even now, I'm not a big fan of it.

---

From: "Neil A. Carson" <[email-masked]>
Date: Thu, 03 Jul 1997 16:35:07 +0100 (BST)

> previous contents.   The 21285 (aka Footbridge) support chip makes this easy

Why not just use the kernel text area?

> in no time and return 0.  This is precisely to make cleaning the D-Cache quicker.

Sounds like the DNARD. Works very well in fact, so much so that you hardly notice
the cleaning at all.

---

From: "Neil A. Carson" <[email-masked]>
Date: Thu, 03 Jul 1997 19:28:26 +0100 (BST)

> did not like the MMU at all.  Even now, I'm not a big fan of it.

Why? As an embedded MMU, it seems perfectly acceptable to me. I guess
the "virtual address" problem comes with the fact that the MMU can run
slower if it doesn't have to cache with physical addresses---which of
course lowers the power consumption.

No doubt someone can correct me here if I'm wrong.

---

From: "Ka'Plaagh" <[email-masked]>
Date: Thu, 03 Jul 1997 15:41:32 +0000