Hi uClinux hackers,
A question just triggered by interest, because I am using this chip -
not with Linux but with a homebrew preemptive multitasking OS.
Does anybody use 68 K uCLinux on a Fido ?
-Michael
___
uClinux-dev mailing list
On 07/30/2013 01:46 PM, Geert Uytterhoeven wrote:
linux-embed...@vger.kernel.org
Hi Geert,
Thanks a lot for the pointer.
Astonishingly that list a a lot less busy than this here :-(
Just to let you (and others) know:
We found out that the idea I had (dedicating one of multiple CPUs in a
I found that this
https://access.redhat.com/site/solutions/15482
answers a lot of questions on that behalf.
It's about Readhat. Maybe something similar is available for Debian, too...
-Michael
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
On 07/30/2013 12:22 PM, Paul Chavent wrote:
I'm not an expert. But i give you my (standard linux kernel) point
of view (don't know if it works with uClinux).
GREAT ! As I have Debian or something similar in mind, this might not
really be uCLinux, anyway. :-)
In fact, is uClinux still defined
Hi Experts.
Is there a kind of official way to set aside one of the available
cores in an SMP system from the Linux OS to do deeply embedded
extremely-low-latency stuff in a kind of single task main loop type
environment ? I.e. creating a true coprocessor from an SMP hardware.
Some of the
On 07/29/2013 04:23 PM, Lennart Sorensen wrote:
Something like this:
http://lwn.net/Articles/464391/
While this is really interesting stuff and closely related (defining a
standard protocol between Linux and coprocessors), I understand that
this article is about using coprocessors that are
Of course you are right, but as here it has been recommended to do
exec() with the same binary, this suggests that something like threads
is what is intended.
If the arch does not provide for reusing code-page memory (via MMU, XIP,
and/or fully relative addressing), loading the binary a
On 08/08/2012 04:04 PM, Michael Schnell wrote:
With volatile the code is a lot worse, I don't understand this, as
the normal code not only fulfills what is necessary to volatile ...
In fact the compiler might be right that volatile also includes
reading and writing all bytes of a variable
You are right.
My compiler also produces this absolutely decent code when not
specifying the variables as volatile.
With volatile the code is a lot worse, I don't understand this, as the
normal code not only fulfills what is necessary to volatile but even
is thread-atomic, as a thread
On 08/07/2012 08:44 PM, Lennart Sorensen wrote:
I wonder where you could get cycle counts for each instruction. I
remember seeing them years ago for 8085 and such, but no idea of
freescale provides them.
I remember that the 68332 documentation does provide cycle count. the
calculation is
On 08/08/2012 12:35 AM, Gavin Lambert wrote:
Not sure if these are applicable to the FIDO as well, but there will
probably at least be similarities.
Innovasic claims that for most instructions the cycle count is equal or
lower. But there might be some exceptions. But they don't provide a list
On 08/03/2012 05:42 PM, Lennart Sorensen wrote:
My understanding is that the coldfire is still m68k, but has dropped
BCD support as well as some addressing modes from the instructions.
Yep. I suppose the addressing mode restriction might in fact be the
problem I see.
The examples I observed
On 08/03/2012 07:46 AM, Greg Ungerer wrote:
Do you know what version of gcc it uses?
Thanks a lot for answering !
fido-none-elf-gcc.exe --version
fido-none-elf-gcc.exe (Sourcery G++ 4.4-186) 4.4.1 Copyright (C) 2009
Free Software Foundation, Inc.
This is free software; see the source for
On 08/03/2012 11:48 AM, Luis Alves wrote:
At the moment I'm still using gcc 4.2.x
In fact I have been provided with a 4.4.x version.
So I am slightly better off.
-Michael
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
On 08/03/2012 11:48 AM, Luis Alves wrote:
At the moment I'm still using gcc 4.2.x
I would be thankful If you could check whether in your projects, gcc
creates code that sets ad checks bits in memory and does memory/memory
operations when appropriate.
I feel
volatile int xx, xy; xx |= 0x80;
On 08/03/2012 03:34 PM, Luis Alves wrote:
Since the volatile tells exactly that you want to use registers during
the manipulation of those variables, so I'm not surprised that it
doesn't change memory contents directly.
Ooops.
AFAIK, volatile means something like:
this memory location is
On 08/03/2012 04:07 PM, Greg Ungerer wrote:
The compiler is still free to read into a register, work on the value
and then write it back. As long as the read and the write do still
occur.
Yep I do know this. Using volatile I just wanted to ensure that in fact
the memory cell is accessed. But
Hi Experts,
This is rather off-topic, but I don't know where else I might find
experts on this.
I do development for the Innovasic FIDO processor, which is an 68 K
CPU32 architecture, in fact a kind of upgrade tho the ubiquitously
used 68332 chip.
The Eclipse based IDE called Sourcery
On 08/17/2011 12:17 PM, Philipp Brejcha wrote:
I did not really find some descriptions concerning SLIP an uClinux.
Obviously you need a description concerning SLIP and UBoot.
Maybe you'd better ask in a Denx forum.
-Michael
___
uClinux-dev mailing
David Wooff wrote:
Hi,
re subject, would it be inappropriate to use read and write calls to
communicate with a 32 bit wide interface?
The fpga cannot accept byte accesses and nor do I want it to anyway.
So, should I control the file position so it can
only ever be on 32 bit boundaries and
Martin Mensch wrote:
PIC32?
I heard rumors that Microchip is going to offer a PIC32 chip that can do
Linux. I don't know if this chip will have enough internal memory or if
external memory chips needs top be used.
-Michael
___
uClinux-dev mailing
piedg...@gmail.com Wrote:
I think i can do any app using cgi only, for embedded. Your problem is
how to parse the name and value out, and, then, writing some simple
app is so easy. Why fastcgi is needed?
I need FastCGI) because I might try to use ExtP (which is a Component to
enable
Erwin Authried wrote:
I heard those rumors about Linux too, seems to be
a gag from Microchip's marketing guys.
Of course the current chips can't do Linux. They seem to be planning a
new chip. But I have no idea wheather it will host a huge RAM or if it
features an external RAM bus.
I feel that
I'd like to do a Fast CGI application on a uCLinux-dist created system.
For normal CGI I successfully use boa as a web server.
Does boa support FCGI (I did not find any notice of that)
If boa does not support FCGI, what other light weight web server can be
used for FCGI ? I found a notice that
David Wooff wrote:
It's slightly complicated because my FPGA is effectively a bridge to a
number of hot-pluggable
backplane I/O cards.
This is similar to (e.g.) USB, SPI or I²C. Linux defines Subsystems
for this kind of devices: The complete subsystem bus is accessed by a
definable driver
thiago wrote:
Is there a tool that simulates platforms that I can use to test my
kernel build?
I suppose this depends on the hardware you are intending to have the
Kernel run on. (X86: VMWare, Virtual Box,... ; ARM: Armulator, ...; ...)
-Michael
I'm using boa as a web server and haserl as a cgi program that does not
need any CGI-programming in c to have the browser current states of the
device (as long as same are accessible by command line programs (such as
echo or cat) e.g. as files real files, or pseudo files like device
drivers or
Jamie Lokier wrote:
Look up comet/long-poll/long-get/reverse-ajax
(all names for the same thing). I'm implementing it now for a board.
Do you do so on top of - or working through - boa or some other standard
browser ?
I might be interested in using this, too.
-Michael
OOps:
... standard http server
-Michael
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
Mike Frysinger wrote:
i just added printf as a builtin. should show how easy it would be to add
cat
as a builtin:
http://git.busybox.net/busybox/commit/?id=4ebc76c8a23367eaec29931b77e10e3ee890dd7d
I'll take a look.
I feel that it should be configurable with make menuconfig if
IIRC, cat is not built-in with hush (unfortunately !).
-Michael
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
Arthur Wong wrote:
and msh have a limitless
cycle as the original init program.
Please do switch to hush, as msh is phased out.
-Michael
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
You can use any executable as init, either by calling the file init,
doing a link called init or define the file in the Kernel parameters.
You can use a script as an executable by defining the interpreter in the
first line e.g. as
#!/bin/msh
Anyway msh is depreciated since some time, you should
Arthur Wong wrote:
I have write a small c program (only use the system() function to run
/etc/rc), and build as init.
AFAIK, not necessary thus not recommended.
The init program (or script) of course should not return (stop), as it's
the parent of all processes.
-Michael
I feel noMMU might give better performance.
I suppose this greatly depends on the chip available and the application
you want to do.
Regarding the processor chip, with most brands the MMU and non-MMU chips
will differ in much more than just the MMU-ness: different clock
frequency, different
Goran Bilski wrote:
Hi,
MicroBlaze soft processor only uses physical addresses on the data cache.
For the instruction cache, we use virtual addresses and to avoid aliasing
problems we use process ID as part of the cache tag.
This also has the benefit of avoiding flushing of the instruction
tom gogh wrote:
Which means, if I use MMU/noMMU in both cases, I need to do less rework or
no rework and easy software maintanability.
Are you targeting userland software or Kernel Work ?
Normal userland software should not be greatly affected by the MMU.
A common problem here is fork()
李 軍 wrote:
Actually, our company just wants to buy a target which can run both uClinux
and full linux. I don’t know which target board can. So could you give me
some advice about it?
If you use an FPGA based processor (such as NIOS2 (which I do use,
Altera only), Microblaze (Xilinx only), you
Mike Frysinger wrote:
- next ~1k is user-space atomic code (initialized by kernel at boot)
so when userspace wants to do atomic functions (since the hardware doesnt
support it), it calls the functions hardcoded in this region. when the
kernel
goes to return to userspace, it checks the
Jim Donelson wrote:
With many archs it's not possible to disable/enable interrupts in
user-space.
But, then if you have an MMU, you have atomic instructions.
Why do you think so ?
Maybe with ARM, all of them that have an MMU do have the load locked
instruction. (I'm not very
Jamie Lokier wrote:
Thread 1 Thread 2 Thread 3
[owns the lock] [running] [waiting]
c = atomic_xchg(val, 0);
[c == 2]
if
Jamie,
BTW. I am going to open a new thread here on implementing the Futex. I'd
be happy if you could join.
-Michael
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by
futexes dont require a MMU.
I do know this, but I intend to use the upcoming NIOS/MMU architecture
and I was told that Futex is yet to do for same.
there is an include/asm-generic/futex.h and i pointed out that using
sh/include/asm/futex.h, we could create a default generic UP version by
Mike Frysinger wrote:
asm/futex.h is for kernel code, not userspace code
Right, but as you state in the lkml article you mentioned above (part
of) the code in that file can be run in process context.
BTW.: AFAI understand,
in Process Context you can do
- disable interrupt
- do atomic stuff
Seemingly the best instruction to handle these bits is atomic compare
and exchange (e.g. provided by the X86 CPU).
It's actually not the best, because when it returns did not match
you have to loop and try again.
The supposedly best user space implementation for the X86 I found (in
Jim Donelson wrote:
Of course it does - sleeping on a sp means preempt me now.
Thus the spinning loop needs to do a sleep system call.
This means the process gives up it's current time slice. St least with a
non-realtime scheduling paradigm, this makes the wall-clock speed of the
thread very
Jamie Lokier wrote:
compare_exchange is a single architecture-specific instruction; that's
what we're discussing.
Not really. The OP is working with Microblaze, I am working with NIOS2.
Both archs do not have any provision for atomic memory modification at
all, so we need to implement it by
Thanks for the pointers !
-Michael
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
Using Bit 31 for cache-bypassing is a specific non portable feature of
the no-MMU variant of the NIOS2 processor.
So this should be discussed in a NIOS2 forum (niosforum.com or
uclinux-nios mailing list).
-Michael
___
uClinux-dev mailing list
hotmail wrote:
As the title.
Or how to communicate between a uclinux system on cpu_0 and a program on
cpu_1？
As you suggest cpu_1 does not run any formal Operating System there
are lots of possible solutions. Any fast communication will involve some
hardware (e.g. to issue interrupts),
Jamie Lokier wrote:
That's right. It's possible to use atomic_compare_and_exchange for
unlock; it's correct. But you get that extra bit of spinning with SMP,
so atomic_dec is better.
In fact I don't see why Ulrich did the unlock code like this:
if (atomic_dec(val) != 1 ) {
val = 0;
Jim Donelson wrote:
I wonder why (on an SP machine) you don't just disable interrupts for a
few instructions and give yourself an atomic dec?
With many archs it's not possible to disable/enable interrupts in
user-space.
-Michael
___
uClinux-dev
Jamie Lokier wrote:
In Ulrich's
version, all threads are guaranteed to run because there's a FIFO
queue on the futex, modified only by desired scheduling policies.
Great argument !
I'll convert to Ulrich's version.
Thanks a lot !
-Michael
___
Jim Donelson wrote:
All that is really required is an atomic exchange.
Suppose 1 means taken, 0 means free. I do an exchange with a 1. If I got
back a zero, it's mine.
True with a Mutex, not true with a Futex. Here you need a second bit in
user-space that tells the releaser that it is to wake
Michael Schnell wrote:
disables the global interrupt for the next three
instructions.
True for the NIOS, that does not use Flags - but register compares -
for conditional jumps, with an architecture that uses flags, I suppose
you need a lock for four instructions.
-Michael
hotmail wrote:
Make sure the irq of dm9000a is high enough not to have a conflict with
WATCHDOG.
I suppose conflicts between *any* IRQs need to be avoided. I don't
suppose there is any support for shared interrupts in this system.
-Michael
___
I now have a Futex testing program up and running.
It performs three tests on different kinds of Mutex implementation for
threads all running the same code:
Test 1: only one thread, many Mutex calls protecting a small critical
section
Test 2: multiple threads many Mutex calls protecting a small
I forgot to mention, that the test calculates the overhead imposed by
the Mutex code in terms of Wall clock and usage time seconds.
-Michael
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
Jamie Lokier wrote:
...
Interesting stuff !
On noMMU, an alternative to using a vsyscall page is to put the
cmpxchg routine in userspace (in Glibc/uclibc), and tell the kernel
what addresses to check for, with a dedicated system call (just like
set_thread_area has a dedicated system call).
Jim Donelson wrote:
I am amazed that the base design did not have atomic instructions.
I understand that with a (simple) Load-Store-RISC architecture CPU,
that performs one instruction per clock cycle, a lot of additional
hardware (which would reduce the maximum clock frequency) is necessary
to
Jamie Lokier wrote:
You can't implement futex just by touching bits in a processor
register - the whole point of futex is to have lots of different
memory locations representing different locks.
You can do a single (or a few) FUTEX using processor bits. This done
you can use this dedicated
Jamie Lokier wrote:
And if you can do that, you can probably make the custom CPU clear the
flag _automatically_ on return-from-interrupt instructions :-)
Unfortunately the power of custom instructions is not that great with
NIOS2. With a MICO32 CPU that you implement in native HDL code and
Jamie Lokier wrote:
Clever. That's going in my algorithms file.
Thanks for the KUDOs :)
If you have lots of processes running, it'll suffer from scheduling
contention on those occasions when an interrupt happens during the
critical section and causes reschedule(). The process will
- ISR modifies the
program counter on return to userspace by decrementing or
incrementing it by a fixed offset, or to a nearest multiple of
16/whatever.
... and similar tricks:
The ISR needs to know if the value already had been modified (i.e
stored) or not. So it needs
Jamie Lokier wrote:
- Do you have atomic instructions.
- Do you have one CPU or multiple CPUs.
Of course you are right.
Let's assume you have a single CPU and no special atomic instructions.
- Copy the trick used on ARM to implement atomic-compare-exchange
in the
The vsyscall trick is a good one, and works with/without MMU, and
with/without permission to disable interrupts in userspace.
Unfortunately I don't find something about the vsyscall trick in the
Kernel sources not in the glibC sources. But I don't have found the
glibC sources for ARM yet,
Jamie Lokier wrote:
Look in arch/arm/kernel/entry-armv.S for __kernel_cmpxchg,
kuser_cmpxchg_fixup, and all the places where kuser_cmpxchg_fixup is
called in that file.
Here they say:
/*
* The only thing that can break atomicity in this cmpxchg
* implementation is
Jim Donelson wrote:
this pair of instructions are basically an atomic test-and-set on the
microblaze status register.
An atomic operation on some dedicated bits located in the processor
rather than in memory. This is exactly what I intended to do for adding
Futex to the NIOS2 arch. Adding
Theoretically, you could do a benefit for the community and port FPC
(Free Object Pascal) to Blackfin.
I once took a very vague glimpse on that and found that it should be
doable when not using the very complex advanced features of the Blackfin
ISA. Doing special Blackfin optimizations will be
Bhat, Amruta wrote:
Hi,
I use a noMMU environment.
I am using sem_init, sem_wait, sem_post for unnamed semaphores across threads.
So I would try if pthread_mutex_lock() and pthread_mutex_unlock() works
better. I suppose using the pthread... functions for all managing of
threads is the most
hotmail wrote:
Hello,
I am doing a multi-core research project based on uclinux and DE2.
Does anyone has reference for PIO/GPIO driver for uclinux-DE2?
Is DE2 the Altera demo board ?
AFAIK, a PIO driver is provided with the uCLinux for NIOS.
see:
Did you see this ?
http://www.linuxfordevices.com/c/a/News/Strategic-Test-TxStar/
-Michael
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
I found that the toolchain dir was updated and now contains an RSA key
(supposedly for the blackfin git server).
Can this key be used instead of doing the expect trick for accessing
the Server ? How ?
Thanks,
-Michael
___
uClinux-dev mailing list
OOps, sorry, wrong group...
-Michael
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
you have to install not only the shell, but also any helper utilities that
the
script may invoke. currently, that means dirname, expr, grep, mktemp, sed,
rm, xargs. see how it gets real ugly real fast ?
Is this not what CygWin is all about ? (ugly but workable)
-Michael
Vinod Nagare wrote:
Dear all,
I am using uClinux 2.4 on coldfire CPU board.
I have written driver module for a timer interrupt
You asked the same question in the NIOSForum ? What is this all about ?
-Michael
___
uClinux-dev mailing list
Seems like Firefox is sending concurrent TCP connections and Explorer
only one per time.
If this is really true this of course can make a difference if you have
may objects on a page (which I don't have). I don't have an idea why
your device might get slow with multiple concurrent sessions, but
For me, a very complex CGI using haserl script is reasonably fast with
Firefox.
-Michael
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To
Just to test user mode, you don't need to compile init or even
busybox. you can just create a simple program and save it to /init or
maybe /bin/init depending on how the kernel is configured.
Of course being able to to printf() is essential. Is your tty driver not
working yet ?
-Michael
@console,c,5,1
@ttyS0,c,4,64
@ttyS1,c,4,65
Sorry for my ignorance, my ls does not show the @ but this might be
the output format of the program you are looking with. Otherwise this
seems OK.
On my NIOS uClinux system, I see:
/dev # ls -l console
crw-rw-rw-1 root root 5, 1 Nov
Since I'm using Nios, then I don't think they are supporting (yet) XIP
or PIC.
So I'll see if I can solve it by using the exec function.
I'm using NIOS, too.
Did you find the Nios2-dev mailing list
(http://sopc.et.ntust.edu.tw/cgi-bin/mailman/listinfo/nios2-dev) ?
And, yep, the current tool
Does a hallo World program work ?
Does a plain old C program work ?
-Michael
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe
AFAIK, there also are database server programs that just use RAM instead
of files or disks to store the data.
-Michael
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent
Mike Frysinger wrote:
Since the nios2 port is the only one to use ...
Is NIOS now official here ?
-Michael
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by
Bittornado is python. Does python run on uclinux?
Some time ago I did a very primitive test with Python on uCLinux for
NIOS. Python did compile and I could type 1+1 and got 2.
-Michael
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
My question now is, must I convert an unknown number of utilities by
myself
or is there another new compiler switch that I haven't seen.
There are compile-system that just define fork as vfork. This does
compile, but as there are cases when fork and vfork are not workalike
enough, this
Jim Donelson wrote:
Not updating the fat right away is key.
If done right, you will only lose the file(s) you were writing if you
kill power to the device.
If not writing right away you'll lose data in case of power fail.
Catch :(
-Michael
___
You will always lose data in case of a power fail with FAT. No matter
what you do.
I don't think so. Provided you define the file system parameters to
immediate commit and hold the CPU in Reset for some while the SD-card is
powered form a battery 10 seconds to let it do it's wear leveling
(because even with immediate commit there is still always a window
where it has not yet been written).
Agreed.
-Michael
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was
Jim Donelson wrote:
No, it is not the erase block size. Yes, the _erase_ blocks are much
larger, and there lies the problem. If you don't do multiple block
writes for consecutive sectors, you will end up causing an erase for
each block you write on the erase sized block.
It will also be
The smallest block size appears to be 512 bytes. The more common
block size is 1024 bytes to 2048 bytes for the larger cards.
Is this really hardware - _erase_ - block ?
Off-the-shelf flash chips use _much_ larger erase blocks to reduce the
price.
-Michael
... This is completely transparent to the host and does not consume
any user data space.
Returning to the start of the discussion:
But is not transparent to the host regarding the time when an operation
is done. This makes switching power off dangerous.
-Michael
While they may exist, I have not yet encountered a SD card with a
block length 512 bytes.
He was talking about internal block size which might be that size (which
I in fact doubt).
The externally visible block size of course always is 512 bytes.
-Michael
but most people are naturally a bit cautious
about touching GCC and Binutils, so it doesn't happen until someone is
really interested or is being paid to do that specific work.
As nowadays, more and more of the new archs do have MMU, I doubt we will
see much more non-MMU archs with theses
... you support __thread. the latter is just a keyword
to gcc to tell it to generate TLS relocs against the specified storage.
If the ggc-version is not constructed to support __thread, I don't think
you can tell it to do so, as gcc needs to know how to support __thread
(e.g. x86 uses
You get the ability to memory map files. Handy for some tasks.
mmap() does work without an MMU.
-Michael
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by
1) After writing to the SD card, close all files.
2) unmount the sd card
3) sleep for 10 seconds
4) send reboot command
5) once out of uClinux, de-power the board
Does this look OK?
Yep.
But only, if you can be sure that nobody switches off power while the
device is working normally.
Someone threw a number into the discussion and said enabling the MMU would
cause performance losses of about 30-40 percent, thus if we switch to Linux at
all it would have to be ucLinux.
uCLinux does not mean without MMU. uCLinux does support several
architectures with MMU.
The numbers
So, only looking at processing power is only half of the story.
Agreed !
Even there is no real technical cause for this, most non-MMU Linux
implementations seem not to support several important features needed
for doing multithreaded: TLS, NPTL, __tread keyword in C, really user
space
If there are many context switches, cache flushing/reloading is the main cause
of slowdown. The exact amount of slowdown depends on your application.
No need for cache flushing when switching the context with decent
cache designs (like x86).
-Michael
1 - 100 of 339 matches
Mail list logo
