XTC Tools 15.0.6 released
Posted: Fri May 28, 2021 9:21 pm
plus new goodies on github. Maybe things are finally moving.
The community of XMOS. The place to be when developing with XMOS technology.
https://www.xcore.com:443/
Code: Select all
Release Notes for Development Tools: 15.0.6 (build: 445-3976dcf)
================================================================
Previous major release: 14.4.1 (build: 235-acbb966) (rc3)
OVERVIEW OF CHANGES SINCE LAST MAJOR RELEASE
--------------------------------------------
* Added support for development using xcore.ai family of products
- Compiler support for new architecture. In particular, new FPU instructions
supported
- Simulator support for architecture core and chip-level features, including
use of external memory and "software memory" via the new minicache
- Assembler support for writing VPU code and new instructions
- Debugger support for new architecture
- XTAG firmware support for JTAG interface
- Support for XCORE-AI-EXPLORER board product
- Continued support for existing xCORE-XS1 and xCORE-200 based products
* Enhanced support for programming in C
- Inclusion of the lib_xcore system library and headers marks a shift in
emphasis towards programming the xcore in C, rather than XC
- The lib_xcore system library allows equivalents of XC constructs including
select{} and par{} to be written without leaving the C language
- XC compiler still included, though it is recommended that new code be
written in C
* Removed xTIMEcomposer IDE
- Marks a move towards allowing developers to partner the XMOS tools with a
development environment of their choosing
- Greater emphasis on command-line usage of the tools and the debugger
* Removed xta static timing analysis tool
- Internal and external surveys point to very low usage of this tool
* xflash
- Support for xcore.ai added
- Now supports use of "software memory"
* The discontinued xtag2 is now unsupported
- Users should upgrade to the newer xtag3 or xtag4
Yes, specifically I was wondering about the notification feature. It helps a lot to keep things a bit more asynchronous. It would be nice to see some examples of code porting, how they expect us to implement combinable and distributable tasks, etc.akp wrote: ↑Fri Jun 04, 2021 1:07 pm It's fairly easy to call interface functions from C using a wrapper XC file passing the interface as an unsigned, so I don't think it will be a problem in most cases. I don't know if you'll be able to use the notification features (didn't look into it). You'll probably need to pass the interface into the C task from the stub main.xc or whatever it is that's still needed. Eventually it will all go away and there won't be "interface" anymore.
Like I said, I don't see changing to using C. I use XC where it makes sense, C where it makes sense, and assembly where it makes sense. I think that's the optimal approach. I haven't looked deeply into XMOS's select implementation (for C) but that in particular looks cumbersome. And I don't like that they've taken away [[combinable]] tasks -- I use those extensively.
At the end of the day, I'm probably a luddite but not a complete idiot -- I understand why XMOS is doing it. They need to appeal to the lowest common denominator. I just think it's a dumb idea from my perspective.