Intel arm xscale, mmx wireless examples? - Page 1
Forum section: electronics / general

author: DiTBho
author_rank: Super Contributor
timestamp: May 01, 2025, 09:03:24 pm
content: Looking for assembly examples.Has anyone ever programmed anything with this Intel extension to the arm-v5 isa?(I think it was 2004, or something)

author: amwales
author_rank: Regular Contributor
timestamp: May 01, 2025, 11:23:20 pm
content: I was a developer at Adaptec when we built the ds300 and ds400 for IBM. The enclosure housed two swappable controllers, for redundancy. Each controller had an xscale processor and was responsible for providing highly available SAN storage. The ds300 was iscsi and ds400 fibre channel. Sadly we benchmarked the xscale memory bandwidth through linux and it was an appalling 50MB/s I shit you not. If you used c++ you were in for a ride as the runtime linker took a couple of seconds to do its thing before your application started.The only way we managed reasonable performance as an IO controller was through a zero copy interface we developed for linux through our iscsi stack. We started development with a linux distribution for xscale and later rolled our own based on LFS. I think the version that was supplied with the single dev board was called hardhat linux. Sadly I didn't keep any boards. I have seen them pop up on ebay, though a quick search doesnt show any.

author: DiTBho
author_rank: Super Contributor
timestamp: May 02, 2025, 09:46:40 am
content: Umm, I am working with xscale pxa270 on an ultra mobile GNU/Linux stuff, made in Japan around 2004-2005The "mmx extension" sounds interesting stuff.Kernel 2.6.23, trying to move to 5.4.229.The rootfs profile is arm-v5te-softfloat, built myself on GNU/Gentoo Catalyst.

author: eutectique
author_rank: Frequent Contributor
timestamp: May 02, 2025, 11:23:48 am
content: Back in 1999 I worked for a company which developed Intel performance primitives for image and signal processing, ippi and ipps. One of the architectures was xScale.

author: DiTBho
author_rank: Super Contributor
timestamp: May 02, 2025, 12:19:25 pm
content: Did you use the mmx-extensions ?If so, do you have any assembly file showing a real use-case?

author: eutectique
author_rank: Frequent Contributor
timestamp: May 02, 2025, 01:11:31 pm
content: Yes, we did heavily. I don't have any source code -- it's all Intel's IP and I was under NDA back then.

author: DiTBho
author_rank: Super Contributor
timestamp: May 02, 2025, 01:45:29 pm
content: Accelerating mobile multimedia using Intel Wireless MMX technology (2005)MMX RefManual (1996)Intel-Architecture-MMX-RM-1996.pdf(3209.49 kB - downloaded 76 times.)MMX.pdf(249.01 kB - downloaded 65 times.)

author: DiTBho
author_rank: Super Contributor
timestamp: May 02, 2025, 01:54:16 pm
content: Quote from: eutectique on May 02, 2025, 01:11:31 pmXscale has not been a product or intellectual property of Intel for about 20 years. Patents should be "expired".Anyway, I'm not asking to post code under NSA, but something, that can be made "OpenSource".The goal is to improve the multimedia players on GNU/Linux PXA270 platform, specifically the Zaurus PDA.Sharp did something for their custom Mplayer for Zaurus PDAs, but they never released the source code, and every Open Source Mplayer I've tried is too slow.The MMX extensions were there for exactly that: to speed up media, since Xscale offers nothing but a dummy framebuffer, and there's not even a floating point unit on the chip.I also need to understand how much gcc supports MMX ... if it has been dropped in recent compilers, and if it is therefore the case to resurrect gcc from 2005.

author: langwadt
author_rank: Super Contributor
timestamp: May 02, 2025, 02:50:23 pm
content: Quote from: DiTBho on May 02, 2025, 01:54:16 pmfor an exhibition at a technical museum? won't that ruin the authentic experience?

author: eutectique
author_rank: Frequent Contributor
timestamp: May 02, 2025, 03:03:23 pm
content: Quote from: DiTBho on May 02, 2025, 01:54:16 pmTo clarify -- I have not taken any source code with me when I left the company in 2001. I had several official CD-ROMs at the time, but I have changed 3 countries since then.Google brought me abookwhich comes with a CD-ROM with examples and, perhaps, the ipp.

author: DiTBho
author_rank: Super Contributor
timestamp: May 02, 2025, 03:09:54 pm
content: Quote from: langwadt on May 02, 2025, 02:50:23 pmSHARP had thought of a graphical interface based on QT, on the top of kernel 2.4.Since their QT is is totally incompatible with x11 without a "compatibility layer" that costs thousand CPU cycles,I removed the entire graphical infrastructure. It doesn't even make sense to have QT or X11 on a 640x480 screen.And I use the PDA in text console, with 3 applications that directly use the framebuffer in graphic modea very light pdf readera Mplayeran application I wrote myself for taking notes with a stylus on a touchscreen (which is noisy, and needs kernel support, like filtering, which consumes CPU cycles)No handwriting recognition, saves everything as a bitmap. It's very crude, but works about as well as notes did on the PalmPilotThe problems areif you want to listen to an MP3 while you do other stuff, even light stuff like reading a text file, the music sounds glitchesplaying with kernel preemption mitigates the problem but does not solve itif in the meantime you compile something with gcc, the audio goes haywireif you take a full break, and try to play a video, it goes haywirethis when with the original SHARP software it was possible to do it!Why? because they massively used MMX instructions, and DSP.While the rootfs that I built ... is more for "Arm-v5" than for "Xscale".It DOESN'T use any advanced feature introduced by intel ...... and the difference is visible (and heard, in headphones)- - -Anyway, there is still a user base. Say, at least 50 users in the world.+1, as I use my Japanese PDA daily.

author: amwales
author_rank: Regular Contributor
timestamp: May 02, 2025, 03:30:20 pm
content: We ran into cache coherency issues on the platform if I remember correctly. One major issue was receiving and IRQ to tell us some DMA had completed and when we looked the data had not arrived yet, a little delay and there it was. I cant remember any of the specific I'm afraid. I know Intel released a new version of the xscale dev board that could handle faster memory but we were seeing exactly the same performance, I am talking memory->memory copies, nothing else.

author: DiTBho
author_rank: Super Contributor
timestamp: May 02, 2025, 04:01:26 pm
content: Quote from: amwales on May 02, 2025, 03:30:20 pmExactly the same issue I still have with a few MIPS boards.Yup, a little delay (loop of NOPs) can save your day

author: ejeffrey
author_rank: Super Contributor
timestamp: May 21, 2025, 04:27:42 pm
content: Quote from: amwales on May 02, 2025, 03:30:20 pmThat was a common problem with PCI and similar buses. The issue was that the data path could have switches in it so that an endpoint might finish sending a write transaction before it has been completely received. However, interrupts were out of band with dedicated pins so a device that does the normal thing of "writing data, then fire an interrupt" could result in the interrupt being received before the data write is actually complete. On some peripherals the first step of an ISR would often be to do an IO read to a CSR to check what work needs to be done -- if any, these IRQs were often shared. In this case there is usually no problem -- the CSR read can't jump ahead of the memory write (depending on the bus coherence guarantees). But that adds latency, and wastes CPU time. More modern peripheral designs allow the critical path to avoid CSR access entirely, putting all the needed information in the DMA descriptor table. And this is where you run into these problems, possibly needing to do a dummy CSR read just to make sure the IO is synchronized.The real solution to this was message signaled interrupts (MSI). In this case, the interrupt request is turned into a data packet which travels along the same path as the memory write. That essentially adds just the right amount of latency to the interrupt to let the CPU keep working until the data is actually ready.

author: DiTBho
author_rank: Super Contributor
timestamp: May 21, 2025, 07:36:28 pm
content: Quote from: ejeffrey on May 21, 2025, 04:27:42 pmDid Xscale support MSI?I am working, at the moment, on a MIPS32 SoC.I enabled MSI to solve exactly this problem.On my Japanese PDA (PXA270), it seems there is exactly "writing data, then fire an interrupt" with the CF-NIC.(PCMCIA NE2K-clone, 10/100Mbps)I don't see corrupted data, i see missing data, and a delay fixes that(yes, I'm so tired of Sharp firmware that I'm rewriting it from scratch)

author: ejeffrey
author_rank: Super Contributor
timestamp: May 22, 2025, 12:04:08 am
content: I don't know about xscale, probably not.Not seeing the write completed is exactly the symptom you expect (stale memory). I'm not sure what the distinction you make between "no data" and "corrupt data." The correct solution is not to insert a NOP delay but to do a register read from the device. The register read actually serilizes with the data transfer.

author: DiTBho
author_rank: Super Contributor
timestamp: May 22, 2025, 10:00:04 am
content: Quote from: ejeffrey on May 22, 2025, 12:04:08 amI meant that I initially thought it was a bug in the code part of the tcp/ip stack, which is very complex, and that I didn't have time to test thoroughly.(I'm not using anything written by others, I wrote everything myself, because it's written for my myC compiler, which doesn't like non-MISRA code at all -> it refuses to compile)But that's the point: I never saw corrupted data, I always saw missing data, as if it had never arrived, and yet the interrupts work correctly, and I read the data right in a fast ISR.At that point I wrote a small demo that works directly and only on the transport layer, and here I saw that a simple chain of NOPs (I put 5 of them), "solves" (solve=workaround) the problem.

author: DiTBho
author_rank: Super Contributor
timestamp: May 22, 2025, 10:04:48 am
content: back to the topic ... I just discovered that gcc doesn't support the MMX extension very well.Intel had a C/80 (propietary, and only for Windows) compiler made that spit out code that took much better advantage of MMX and DSP.I think that .... I'll have to write libraries in assembly, rather than trying to find a way to make gcc spit something out.

author: ejeffrey
author_rank: Super Contributor
timestamp: May 22, 2025, 03:31:42 pm
content: Yeah not surprising. In the era this architecture existed most compilers had limited to no support for auto vectorization. Even on x86 mmx was pretty much only used manually with intrinsics or assembly macros. Intel did a lot of the early implementations in the Intel compilers largely as a way to distinguish their professors from the athlons of the day. I guess the idea was that if Matlab and Photoshop used the Intel compilers to take advantage of vector extensions people who wanted to use those would have to buy Intel.It's much more well supported now but ARM-MMX is a dead end architecture so I'm not surprised it's support hasn't improved.