[Oberon] RISC5 clock speed and interrupt context switch
eas lab
lab.eas at gmail.com
Wed Oct 1 03:53:46 CEST 2014
If you're building a world-class racing yaught (sp?), you don't add a
GE-gasTurbine to <increase its performance>.
IMO PO adds the hardware component which is consistent with the style of the
decades-old/confirmed ETHO language/OS. I.e the RISC fits perfectly into
the existing software, to extend the brilliant teaching product.
But nobody wants it. They want to 'update' their classical wheel-barrow,
by adding a jet-engine.
I want to extend ETHO to 'compose functions from a script', instead of manually
as currently: by 'piping' the transformed-stages through TextFrames.
Eg. MANUALLY, with each stage to a new Textframe, we can already do:
showAllFilesNamed Arg1 | whichAreLessTnadaysOld Arg2 | &whichContainString Arg3
| &whichContainString Arg4 | &whichContainString Arg5
But adding a *nix-piping-like ability, to eliminate the manual work, adds power.
Like <OSFS.Tool> added the ability to automatically write the command that
will be executed to do the repetative task. Ie. meta-programming.
--------
AFAIK SHARC is already well documented re. ETHO, and formed the basis of
ALO: the recent version for the rPi.
It seems unlikely that <your product which needs fast interrupt handling>
would benefit from ETHO's strength, which IMO is the human-interface.
== Chris Glur.
On 9/29/14, skulski at pas.rochester.edu <skulski at pas.rochester.edu> wrote:
> Hello:
>
> I am exploring the FPGA-based Project Oberon. Two questions popped up
> after reading the hardware portion of the new Project Oberon and the NW
> Technical Reports from the FPGA-related part of the personal website.
>
> 1. The RISC5 clock speed is 25 MHz. Can it be improved to the Microblaze
> ballpark that is over 100 MHz?
>
> 2. The interrupt HW system. A fast interrupt service can be achieved with
> a set of shadow registers for context switching, used on Analog Devices
> ADSP21xx series and SHARC. Has this been considered for the RISC5
> interrupt system?
>
> I am asking because improving the performance in these two areas could
> make RISC5 (or its derivatives) an attractive option for deeply embedded
> signal processing.
>
> Regards,
> Wojtek
>
>
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon
>
More information about the Oberon
mailing list