@vidarh

Quote:

vidarh wrote: @Hans By "event driven" they mean that the threads can be scheduled based on IO activity and timers. I.e. you can have a thread pause until a byte is written to a specific IO port. This is instead of the "traditional" model where an interrupt would be triggered, and the OS would have to dispatch an event to the proper thread. It allows very low latency / low overhead implementation of "simulated" hardware - their site has examples of things like UART's (it implements a simple serial port in less than a screenful of code), ethernet, a SID implementation etc.

For low latency stuff on a traditional CPU, you stick that code straight into the interrupt service routine. It looks like the advantage is in the fact that there is hardware support for eight threads, each of which can be triggered by events (interrupts). Other than that, it still looks like interrupts.

Hans

_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more. Home of the RadeonHD driver for Amiga OS 4.x project.
https://keasigmadelta.com/ - More of my work.

What I want to know is how will the xmos be accessed...

Will you have too load a program onto the xmos chip through a card or will there be a simple to use AmigaOS interface for it.
something like:

Xena->LoadProgram("PROGDIR:precompiled.app");
Xena->Execute();

Or will there be some other method for it?

Edit:
And will there be an interface for getting information back out of the chip, or will it be a point, shoot, forget thing?

Edit again:
Or will the output/input be up to the program that you put on the chip?

Last edited by BinoX on 05-Jan-2010 at 10:07 PM.
Last edited by BinoX on 05-Jan-2010 at 10:06 PM.
Last edited by BinoX on 05-Jan-2010 at 10:04 PM.

_________________
Back to action!

@-pekr-

Here's some things that people are already doing with these chips:

http://www.xcore.com/projects

http://www.xmoslinkers.org/projlist/

https://www.xmos.com/products/development-kits/usbaudio2

http://www.xmos.com/applications/networking-and-avb

look under Applications here:
http://www.xmos.com/support/documentation

_________________
All glory to the Hypnotoad!

@Hans

Quote:

Hans wrote: @vidarh For low latency stuff on a traditional CPU, you stick that code straight into the interrupt service routine. It looks like the advantage is in the fact that there is hardware support for eight threads, each of which can be triggered by events (interrupts). Other than that, it still looks like interrupts.

Have you looked at their code examples? It does not look like interrupts. You can write imperative style apps and just "read" (or write) a value from a port at any point and that thread will sleep until a value has been written to that port. As such it's far simpler to write than a state machine inline in an ISR. And you can do inter-thread synchronisation through "channels" that behave pretty much like the ports.

It might *behave* somewhat like interrupts, but also not many platforms can provide communication between multiple CPUs with roundtrip latencies down to 200ns reliably using interrupts handled by a general purpose OS.

_________________
Wiki for new/returning Amiga users - Projects: ACE basic compiler / FrexxEd / Git

@Hans

Best I can figure to compare with an ARM SOC ASIC is that if you make something with an ARM SOC ASIC, that is exactly what you have. If your verilog had a bug in it, the ASIC thus has a bug in it. An FPGA implementation of the same ARM SOC can give you a little more bugfixing freedom. An Xcore also gives you some bugfixing freedom to a similar "hardware bug".

As an FPGA card can potentially be different things at different times, I've in the past envisioned an FPGA to dynamically change from one codec to another based on user desire, being an mp3 decoder for this and then being an avi decoder for that, should your needs be like that. Seems like an Xcore could do something similar, morphing from one use to another. And not just as a software core kind of thing, but also possibly changing what IO pins are used for. Have a generic connection, like the Xorro slot, the same chip on the motherboard can service a sound card shaped plugin board, or an ethernet shaped plugin board, or change the audio plugs on a sound card plugin to be more of a generic A/D D/A thing and have a cheesy oscilloscope. I guess changing what shape plugin board whihle the system is running isn't as good comparison as changing what's inside an FPGA, but I guess that so long as you don't need to change IOs, comparing a dynamic FPGA core swap to changing what software the Xcore is running makes some sense.

_________________
All glory to the Hypnotoad!

@Hans

Quote:

Other than that, it still looks like interrupts.

Not sure how correct it is or not, but that's the way I'm making sense of things for the moment too.

_________________
All glory to the Hypnotoad!

I wonder how security would be addressed.

EG main memory:

http://citp.princeton.edu/memory/

_________________
Download 499.26 Mbps, 659.94 Mbps Upload :)

@BinoX

Quote:

Will you have too load a program onto the xmos chip through a card or will there be a simple to use AmigaOS interface for it. something like:

I'd hope that AmigaOS provides some sort of arbitration for the chip. Imagine that you've been running some audio application that utilises all eight threads, and then want to load another application that needs four of the threads to do something else. At a minimum, it would be good to be informed that the first application is hogging the XMOS chip, and given the option to terminate it. On a more advanced level, perhaps applications could indicate to the OS that they can gracefully fall-back to using less of the XMOS's threads, so the user can choose to throttle the XMOS-hogging application and run another...

_________________

@Hans Quote:

For low latency stuff on a traditional CPU, you stick that code straight into the interrupt service routine. It looks like the advantage is in the fact that there is hardware support for eight threads, each of which can be triggered by events (interrupts). Other than that, it still looks like interrupts.

I haven't read their documentation yet, but I get the feeling that the XCore's "interrupts" are virtually instantaneous (as little as 1 clock cycle), where-as "real" interrupts on a normal CPU will take much longer, not least because it has to store registers on the stack (and restore them afterward), not to mention cache overhead.

The XCore has a limited number of "hardware threads" (hardware parallelism), but switching between these threads will be extremely fast, because all the resources (memory) needed to switch between them is stored on-chip. So as long as your XCore code can be fitted into 4-8 threads, it will vastly out-perform a normal CPU doing the same task.

Last edited by ChrisH on 05-Jan-2010 at 10:49 PM.

_________________
Author of the PortablE programming language.
It is pitch black. You are likely to be eaten by a grue...

@asymetrix
AmigaOS doesn't do security. (At least not yet.) It's a single-user operating system, written with the assumption that you are allowed to see & touch everything. That has some nice advantages, when you are only a single user :)

_________________
Author of the PortablE programming language.
It is pitch black. You are likely to be eaten by a grue...

@ChrisH

Quote:

ChrisH wrote: @Hans Quote: For low latency stuff on a traditional CPU, you stick that code straight into the interrupt service routine. It looks like the advantage is in the fact that there is hardware support for eight threads, each of which can be triggered by events (interrupts). Other than that, it still looks like interrupts. I haven't read their documentation yet, but I get the feeling that the XCore's "interrupts" are virtually instantaneous (as little as 1 clock cycle), where-as "real" interrupts on a normal CPU will take much longer, not least because it has to store registers on the stack (and restore them afterward), not to mention cache overhead.

I could be wrong but, IIRC, ARM micros have a separate set of registers for interrupt service routines, kind of bypassing the register saving stuff that others have to do. One advantage that I can see is that, by having hardware threads, your event handling code doesn't have to worry about taking too long, and blocking the main thread, or blocking other interrupts. With a normal CPU, IRQ handlers have to be short, because another interrupt could come in which requires timely handling.

Hans

_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more. Home of the RadeonHD driver for Amiga OS 4.x project.
https://keasigmadelta.com/ - More of my work.

I just had a thought :

depending on how fast the Xcore is we could use LUA to quickly script and access the Xcore for rapid development in an easy to use basic like language.

_________________
Download 499.26 Mbps, 659.94 Mbps Upload :)

@ChrisH

Fair enough - just in case devs had some more ambitious plans up their sleeves - something they may not be aware of.

_________________
Download 499.26 Mbps, 659.94 Mbps Upload :)

@vidarh

Quote:

vidarh wrote: Have you looked at their code examples? It does not look like interrupts. You can write imperative style apps and just "read" (or write) a value from a port at any point and that thread will sleep until a value has been written to that port. As such it's far simpler to write than a state machine inline in an ISR. And you can do inter-thread synchronisation through "channels" that behave pretty much like the ports.

I haven't had time to do much research, so no, I haven't looked at their code. It sounds like their code library and SDK have made these things very easy to handle, but underneath, I see no difference between one XCore thread sitting idle until an event comes in, and a normal CPU sitting idle until an interrupt arrives.

This has gotten me interested though, and I wouldn't mind getting a 4-core development kit when I have the funds.

Hans

_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more. Home of the RadeonHD driver for Amiga OS 4.x project.
https://keasigmadelta.com/ - More of my work.

@Hans Quote:

I wouldn't mind getting a 4-core development kit

X1000 ?

_________________
Author of the PortablE programming language.
It is pitch black. You are likely to be eaten by a grue...

@ChrisH

Quote:

ChrisH wrote: @Hans Quote: I wouldn't mind getting a 4-core development kit X1000 ?

Well, that's got a single-core XCore chip on it, so that's a start.

Hans

_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more. Home of the RadeonHD driver for Amiga OS 4.x project.
https://keasigmadelta.com/ - More of my work.

@asymetrix

LLVM-Lua should already work on the XCore since XCore's development toolkit is already based on LLVM and LLVM-GCC.

@Samurai_Crow

IIRC, you've already done some LLVM related Amiga stuff. So how much effort would it take to get LLVM-GCC and the XCore compiler tools working on Amiga OS 4.x? We're going to want to develop software that uses the XCore chip on the X1000, not on a separate PC.

Hans

_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more. Home of the RadeonHD driver for Amiga OS 4.x project.
https://keasigmadelta.com/ - More of my work.

@Hans

LLVM itself is built with portability in mind so porting it should be easy. The System class encapsulates most of the system-specific functionality.

LLVM-GCC is fairly tough but an easier compiler would be Clang. It doesn't support full C++ yet but works just fine with C code. Clang is going to be the successor of LLVM-GCC because LLVM-GCC is based on Apple GCC 4.2 rather than GNU GCC 4.5 .

-edit2-
Unfortunately the DragonEgg plugin for GCC 4.5 works on x86 and x86_64 POSIX systems only.

-edit3-
The only tricky parts about LLVM-GCC is the build script. The source is supposed to be able to bootstrap with itself but I don't know how well it does since I've never seen a bootstrapped LLVM-GCC work. I've only been able to compile LLVM-GCC with regular GCC on Linux and Mac. Once you have LLVM ported you should be able to cross-compile it from Linux or Mac.

BTW, I'd recommend steering clear of Windows when using LLVM because the VIsual Studio generated codes use incompatible SetJump/LongJump-style exception handling and MinGW is only somewhat compatible to regular GCC on Linux due to using the Visual C++ runtime.

Last edited by Samurai_Crow on 06-Jan-2010 at 01:29 AM.
Last edited by Samurai_Crow on 06-Jan-2010 at 01:00 AM.
Last edited by Samurai_Crow on 06-Jan-2010 at 12:57 AM.

One thing which has been written about but not really explicitly said is that
the main thing about the XMOS chip might be the latency.

In terms of MIPS, the chip does not look all that powerful even if you can
connect a number of them - but the latency on the other hand might
be really good. There are many things, not just audio processing, which
can benefit from dedicated low-latency hardware threads.

Now, I do not know what will be feasible of course but a few examples
come to mind:

The KillerNIC network card (Bigfoot Networks) has some related functionality.

Any type of sampler - could it be possible to build a spectroscope by basically just adding
a cable and a connector?

Accurate emulation of e.g. SID chips or other older chips (m68k? copper?).

High-speed serial ports


Well, what do you think? Is latency more important than processing speed?