Best RETARGETABLE C compiler for FPGA CPU projects? - Page 1
Forum section: electronics / general

author: plainsteve
author_rank: Newbie
timestamp: January 17, 2020, 07:02:24 pm
content: One of my bucket list items is to create a CPU (on FPGA) which can play Doom at 320x200(or 240) and then move to Quake 1 at 640x480. One major setback is a lack of a C compiler which is accessible enough to actually retarget by a person who does not wish to spend his career as a compiler specialist. I've looked at LLVM on and off over the last 6 years, but their documentation is awful and I don't have the time to chip away at that behemoth.Can you suggest a decent quality C compiler that is retargetable by someone knowledgeable about compilers but not an expert?Thanks!

author: ataradov
author_rank: Super Contributor
timestamp: January 17, 2020, 07:08:16 pm
content: Realistically any advanced compiler will require a lot of effort to retarget.TCC seems like your best bet, but I'm not sure it actually supports enough of C to compile Quake. I bet Doom won't be a problem though.As an alternative you can create a core for already existing architecture (like RISC-V). This will move the project forward fast and if you still feel like doing it, you can replace the core at a later time when all the peripherals are working.

author: Berni
author_rank: Super Contributor
timestamp: January 17, 2020, 07:55:10 pm
content: Yeah if you are using a FPGA then its best to just make the softcore CPU compatible with some sort of existing instruction set. There are a lot of instruction sets out there so im sure you will find one that works for what you are trying to make.Just make sure to use a instruction set that is reasonably high level language friendly so that the compiler will have a easy time making fast optimized code for it. So you may need to chose a bit more complex of a cpu core or you might have to run your softcore CPU at a fairly high speed to compensate for the slow software.

author: rstofer
author_rank: Super Contributor
timestamp: January 17, 2020, 11:29:27 pm
content: It would be best to just use a core provided by the FPGA manufacturers like Intel (Altera) NIOS or Xilinx MicroBlaze.If you really want to do it the hard way with a custom core, consider using LCC.https://en.wikipedia.org/wiki/LCC_(compiler)https://www.amazon.com/Retargetable-Compiler-Design-Implementation/dp/0805316701

author: langwadt
author_rank: Super Contributor
timestamp: January 18, 2020, 12:24:18 am
content: Quote from: rstofer on January 17, 2020, 11:29:27 pmhere's an example of an FPGA cpu core and LCC,http://www.fpgacpu.org/xsoc/index.html

author: SiliconWizard
author_rank: Super Contributor
timestamp: January 18, 2020, 12:55:08 am
content: Quote from: ataradov on January 17, 2020, 07:08:16 pmTCC is probably much easier to write a new target for than LLVM or GCC.But as to your remark? You must be kidding, or haven't looked at it in a long while. It's fully C99 compliant, and supports a sizable portion of C11 as well (including Generic). I've tried compiling a wide variety of projects with it and found no issue. It's also blazingly fast.It's become very good actually. Only downside is, of course, that it does very little optimization (which explains why it's so fast and why it's relatively easy to modify). It has ARM and ARM-64, x86 and x86-64,RISCV-64 and oddly C67, so that's a few targets there, should be good to get you started writing a new one.As I said above, it does little to almost no code optimization, so keep that in mind if you're going for it, but other than that, it's very good.

author: ataradov
author_rank: Super Contributor
timestamp: January 18, 2020, 01:01:16 am
content: Well, I was not worried about standard C support. But I have no doubt that Quake code contains inline assembly and SIMD intrinsic. I don't know if they can be easily disabled. I have never seen Quake source code.

author: SiliconWizard
author_rank: Super Contributor
timestamp: January 18, 2020, 01:16:57 am
content: Quote from: ataradov on January 18, 2020, 01:01:16 amOK, this partQuotewas probably kind of confusing to me. Inline assembly is not C, and so supporting it is not supporting "enough of C". Its support is not standard anyway so if there's any, it could be hard to compile with any other compiler than the one used initially. Besides, the OP is thinking about creating a non-exisiting CPU as far as I got it? So existing inline assembly would be useless whatever the compiler is. Just my 2 cents.And that said, for the record, TCC does support GCC's extension for inline assembly:https://bellard.org/tcc/tcc-doc.html#GNU-C-extensionsso porting that to a new target should also be doable strictly focusing on the target (back-end).

author: plainsteve
author_rank: Newbie
timestamp: January 18, 2020, 02:42:09 am
content: SiliconWizard wrote:QuoteYes. I want to make a CPU of my own design.* * *Thanks for comments. So far, LCC 4.x, TCC, and something I came across called SDCC seem worthy of investigation.Open to more suggestions, though.

author: ataradov
author_rank: Super Contributor
timestamp: January 18, 2020, 02:43:21 am
content: Don't bother with SDCC. It definitely does not support enough of actual basic C to be usable. It is barely usable on 8-bit MCUs, which it targets.

author: SiliconWizard
author_rank: Super Contributor
timestamp: January 18, 2020, 03:26:32 pm
content: SDCC is 8-bit only AFAIK indeed? I've used it for 8051 targets (Cypress FX1/FX2) and it was fine for that, knowing all the limitations those processors have.If the OP intends on developing an 8-bit CPU, that would actually be a wise choice (as the others we cited don't support 8-bit targets easily or at all I think?), but otherwise, I agree it would be useless.

author: laugensalm
author_rank: Regular Contributor
timestamp: January 18, 2020, 06:14:54 pm
content: Why don't you just pick a RISC-V and add some Bresenham rendering engine that you can drive with your own 'inline' assembly?That way you might really focus on the fun stuff and base on a well tested compiler. Plus, you'd possibly have some seriously reusable IP in the drawer.Other than that I found the LCC pretty interesting for wild CPU architecture hacking (actually, on a sidenote, there's an interesting CPU concept 'X32' that seems to understand the LCC bytecode directly). However, at that time the LCC had troubles with designated initializers, IIRC.When going 'classical register style', I think you can't be much different from a RISC-V, it's kind of a logical attractor architecture. You could of course consider different concepts, like stack machines (e.g. ZPU, there's also various DOOM hacks, likehttps://turbogrill.blogspot.com/2014/06/doom-on-zpu.html)

author: rstofer
author_rank: Super Contributor
timestamp: January 18, 2020, 06:54:47 pm
content: A couple of man-weeks to design and implement a CPU in an FPGA but from what I see, man-years to retarget the compiler. SDCC doesn't seem to be over-friendly in that area and I haven't tried retargeting LCC. LCC started out as a compiler specifically for retargeting so it may be a great deal easier to modify than SDCC,That's why I would pick a CPU for which a toolchain already exists. Designing compilers is not a job for mere mortals.Many of the text based games were available on the PDP-11/70. Well, there is the PiDP-11-70 which is a really good emulation and runs several operating systems including BSD 2.11 which is very similar to BSD 4.3. It is based on a Raspberry pi with the SIMH simulator package simulating the PDP-11/70. I have two of these machines and I really enjoy writing little code snippets in C, Pascal or FORTRAN. I have no particular application but I do have a web server on each (yet to have any interesting content). Berkeley Sockets works well! Somehow, that seems really important, to me...https://obsolescence.wixsite.com/obsolescence/pidp-11There are competing goals: 1) Play the games, 2) invent a CPU and 3) retarget a compiler.For mere mortals, goal 3 is out of the question which kills goal 2. It would be far better to pick a CPU (like the Z80) for which tools already exist (CP/M, C, Macro Assembler, FORTRAN, PL/I). To that end, I recommend the T80 core at OpenCores.org. It is a cycle accurate Z80 and I used it to implement CP/M (and friends) on a Spartan 2 about 15 years ago. It was as easy as adding a Compact Flash to the bus, writing the BIOS code, loading the disk image (I forget how I did that, today I would use Linux 'dd') and it was up and running. A really fast Z80!Again, I picked a CPU for which tools already exist. In fact, I used the 22Nice Z80 emulator, running on a PC, to allow use of the Digital Research Macro Assembler to write the BIOS. Ultimately, I had Kermit running and I transferred the bulk of the files from a CompuPro (real) Z80 which used 8" floppies. Pretty cool to watch that old dog feed files to something like an FPGA Z80 CPU.The T80 initially came up because I wanted to recreate PacMan - in fact, PacMan got me started in this adventure with FPGAs. I have it running on a Nexys 2 board.https://www.fpgaarcade.com/kb/pacman/BDS C Compiler (started in 1979) for the 8080/Z80https://www.bdsoft.com/resources/bdsc.htmlShort answer: I would avoid retargeting a compiler at any cost. To that end, I would avoid designing a custom CPU. We're talking about man-years of work (as a guess) to get that C compiler running. Don't forget, the emitted code has to pass the regression tests - all of them! But even the tests need to be retargeted. The compiler becomes the project and that isn't the original goal.One alternative might be to manually convert the C code to asssembly language. An assembler for a custom CPU could be written in Python in a couple of days. Maybe a week if there is any desire to have a listing. There are examples on the web. A Macro Assembler would be far better.I thought a lot of these text based games had been ported to the Z80 (with CP/M?).

author: brucehoult
author_rank: Super Contributor
timestamp: January 18, 2020, 07:41:41 pm
content: PDP11, MSP430, M68k/Coldfire, SH4 form a kind of family of ISAs that are quite pleasant to program in assembly language and relatively easy to write a decent compiler for. The PDP11 doesn't really have enough registers (8, with 5 or 6 available), and the others double this in different ways. The last two in the list have the big advantage of being 32 bit. They have nice compact code, though no real advantage over variable-length Thumb2 or RISC-V with the C extension.They're all pretty easy to implement using a microcode approach, but very difficult without, so they're going to lose out in speed to RISC, which is effectively its own microcode.I don't know where you'd find a compiler for modern C targeting the PDP11. The others are all supported by gcc and/or llvm.The 8080/z80 are just ugly. They're extremely difficult to make good code for, either hand-written or with a compiler, and the code tends to be huge, and they also need microcoding to implement. And 16 bit address space. I'd stay away unless you specifically have existing code you want to run -- CP/M, wordstar, old games etc.6502 is much the same, in a different direction. It's easier to implement, and easier to hand or machine write code for once you wrap your head around zero page being the registers, not the actual registers :-)6809 and 8086 are a huge usability improvement over their predecessors both for hand-written and compiled code, and code size. But you're just so much better off going for something similar to ARMv2, MIPS, RISC-V for implementation simplicity, speed, and ease of compiling for.Transputer would be an interesting wildcard. Very easy to implement the basic integer ISA and should be easy to write a compiler for. You can make it 16 bit, 32 bit, 64 bit or whatever you want as the actual ISA just doesn't care!

author: rstofer
author_rank: Super Contributor
timestamp: January 18, 2020, 08:39:23 pm
content: Quote from: brucehoult on January 18, 2020, 07:41:41 pmOn any of the Unix (BSD) releases for the PDP-11. BSD 2.11 is my favorite of those that run on the PiDP-11 simply because I understand Unix (a bit) but I know nothing about the other DEC OSes. They might be learnable but they are not compelling - to me.BSD 2.11 has everything! C (along the lines of the ORIGINAL C, as used to create Unix), FORTRAN and Pascal (a Berkeley creation). No, the C doesn't comply with any of the later standards but is exactly K&R C as given in "The C Programming Language" book (original, pre-ANSI edition). If it was good enough to create Unix, it will probably handle Doom.For giggles, attached is a screen shot of a Telnet session into a PiDP-11/70 and a listing of the /bin directory. CC shows up, FORTRAN and Pascal are elsewhere.OK, the PiDP-11 project is based on a Raspberry Pi but there is a parallel project using an FPGA incantation to implement the same setup including all of the OSes. Most important, to me, is BSD 2.11.Here is the project:http://pdp2011.sytse.net/wordpress/So, it is possible to run BSD 2.11 on an FPGA inside the nifty console of the PiDP-11. Now we're talking retro!A lot of games were written for the PDP-11s (and the PDP-8s).

author: ale500
author_rank: Frequent Contributor
timestamp: January 19, 2020, 06:27:39 pm
content: There is the bkunix project, the cross-devel directory has all the tools for the pdp-11, assembler, linker, compiler. I compiled them on linux on windows, they work pretty well.https://github.com/sergev/bkunix/tree/master/cross-devel

author: dsula
author_rank: Newbie
timestamp: May 19, 2024, 06:40:15 pm
content: Use vbcc athttp://www.compilers.de/By the far the simplest retargetable C compiler out there. I'm no compiler expert but was able to write my own backend for several of my own CPU creations.

author: rstofer
author_rank: Super Contributor
timestamp: May 25, 2024, 01:27:52 pm
content: A retargetable C compiler:https://www.amazon.com/Retargetable-Compiler-Design-Implementation/dp/0805316701

author: gnuarm
author_rank: Super Contributor
timestamp: May 25, 2024, 01:42:59 pm
content: People seem enthralled by C. I'm not such a big fan. I much prefer to work in forth. But then, I'm not trying to port C code.A forth oriented CPU is very easy to make in an fpga. They can be small and if you know how to design in an HDL, they can be very fast. Your forth CPU can be programmed in forth to "interpret" x86 opcodes as an intermediate language. Then you can still program it in C.

author: langwadt
author_rank: Super Contributor
timestamp: May 25, 2024, 10:04:43 pm
content: Quote from: gnuarm on May 25, 2024, 01:42:59 pmwhat does x86 opcodes have to do with c? x86 didn't even exist when c came about

author: gnuarm
author_rank: Super Contributor
timestamp: May 26, 2024, 03:57:16 am
content: Quote from: langwadt on May 25, 2024, 10:04:43 pmExisting compilers will compile C code for an x86 processor. Your forth target can emulate an x86 and run the compiled C code. I believe the C compilers still support the early x86 processors, like the 8086, 80286, etc. So, you don't need to worry with the full, modern instruction set.Meanwhile, your forth target will run forth to provide an interactive scripting language.

author: RoGeorge
author_rank: Super Contributor
timestamp: May 26, 2024, 06:02:59 am
content: Quote from: plainsteve on January 17, 2020, 07:02:24 pmIf I got it right, this is a hardware exercise in designing a CPU + a video out. I will assume you know that there are already examples of similar FPGA implementations, but you want to design your own.If so, I would just take the instruction set of an existing CPU that already has a port for existing C compilers, and design the CPU compatible with that instruction set.Side note, having a C port for the new CPU might not be enough. Depending on how innovative is the architecture of the new CPU, it might also need an assembler and a linker written from scratch (maybe a dissasembler and a debugger, too), aside from the C port.

author: brucehoult
author_rank: Super Contributor
timestamp: May 26, 2024, 06:42:45 am
content: Quote from: gnuarm on May 26, 2024, 03:57:16 amYes you could do that, but there is no reason to think that x86 is the best ISA to use for this purpose. Almost anything else (at least 16 or 32 bit) I can think of would be better.x86 is just about as annoying to parse / decode in software as it is in hardware. Perhaps even worse, it is EXTREMELY annoying and slow to emulate condition codes on a machine with different condition codes or even different rules for setting them (or none at all). In a JITting emulator that can give a 2:1 slowdown, but in an interpretive one (assuming trivial instruction code, which x86 doesn't have) it can be 5:1 or worse compared to emulating an ISA without condition codes.

author: gnuarm
author_rank: Super Contributor
timestamp: May 26, 2024, 07:58:07 am
content: Quote from: brucehoult on May 26, 2024, 06:42:45 amYou seem to be swimming against the flow. If you can't figure out how to deal with this issue, then you should not be working on the problem.You have total control over the hardware CPU, and the x86 emulation. There is no reason to make the problem difficult.

author: brucehoult
author_rank: Super Contributor
timestamp: May 26, 2024, 09:05:18 am
content: Quote from: gnuarm on May 26, 2024, 07:58:07 amOn the contrary, I have academically published (and frequently cited) work in this area (high performance RISC-V emulation on x86), have commits in QEMU and Spike (Golden Reference RISC-V emulator), and have worked on JITs for Javascript, C# and others.

author: gnuarm
author_rank: Super Contributor
timestamp: May 26, 2024, 09:33:07 am
content: Quote from: brucehoult on May 26, 2024, 09:05:18 amThen, why are you making a simple problem difficult?

author: laugensalm
author_rank: Regular Contributor
timestamp: May 26, 2024, 09:35:24 am
content: Quote from: gnuarm on May 26, 2024, 03:57:16 amThat might be possible in theory, but is complete nonsense from an engineering perspective.I'm well aware of the Forth niche, and I've seen funky things indeed, like UDP stacks written in Forth running on a enhanced J1. But emulating a register architecture on a stack machine introduces a massive overhead, not just from emulation side, let aside a horribly designed x86 legacy.It is actually easier to get a new core designed and verified according to a regression test of an existing compiler suite than the other way, designing a compiler backend, *if* full coverage is required. Else, LLVM can give you quick results as well, question is, whether the C frontend then still makes sense compared to Python code generation.C is good for porting stuff and is understood by almost all. That's just that.I just realized how old this thread was, and that I already posted on DOOM on the ZPU (still a very nice stack machine, being actively used). At the end of the day, the engineering question specific to a CPU SoC is: Will it still fit on my FPGA and can I program it with a standard gcc?To give an example about hard limits: I need to run a bare metal 'OS' with RPC functionality (UDP/IP) in 32kB RAM. RV32c (compressed ISA) is getting close, ZPU can do, i.e. provides the optimum relation of gate count and code density and obviously beats x86-opcodes in the latter discipline.Would I really even consider inserting an emulation layer?

author: mikerj
author_rank: Super Contributor
timestamp: May 26, 2024, 10:15:29 am
content: Quote from: gnuarm on May 26, 2024, 09:33:07 amHe isn't, simply pointing out how complex your "simple" solution would be in practice.

author: gnuarm
author_rank: Super Contributor
timestamp: May 26, 2024, 03:19:59 pm
content: Quote from: mikerj on May 26, 2024, 10:15:29 amSure, you can make anything difficult, if you really want to.

author: langwadt
author_rank: Super Contributor
timestamp: May 26, 2024, 03:53:08 pm
content: Quote from: gnuarm on May 26, 2024, 03:19:59 pmand you can say anything it simple and easy if you haven't done it

author: Berni
author_rank: Super Contributor
timestamp: May 27, 2024, 05:28:50 am
content: Quote from: gnuarm on May 26, 2024, 03:19:59 pmGo ahead and try to write a x86 emulator in forth and see how 'simple' it really is (especially if you want to support a fairly modern variant of x86)The simple solution is to take a existing simple ISA (like a 6502) that has existing compilers for it and just implement that. These old ISAs are already designed to be simple to use while getting a reasonable amount of performance out of a small number of transistors. You could still add your own custom extensions to a popular instruction set.

author: SiliconWizard
author_rank: Super Contributor
timestamp: May 27, 2024, 06:01:36 am
content: Q: Can you suggest a retargetable C compiler?A: C is obsolete, use Micropython.

author: abeyer
author_rank: Frequent Contributor
timestamp: May 27, 2024, 11:49:05 pm
content: Quote from: SiliconWizard on May 27, 2024, 06:01:36 am...just so long as you already have a working c toolchain to build micropython

author: EEexpert
author_rank: Newbie
timestamp: May 28, 2024, 06:39:10 pm
content: Tiny C compiler would be a good choice.A competent C developer can add new CPU arch to it in a couple of weeks if it's his first arch, next one may need just a couple of days. Very good knowledge of the instruction set for the target arch is required.

author: Canis Dirus Leidy
author_rank: Regular Contributor
timestamp: May 29, 2024, 02:31:20 pm
content: Quote from: gnuarm on May 25, 2024, 01:42:59 pmWhy bother with emulation at all, instead of taking a ready-made core like ao486/s80x86/MCL86? If, of course, the task is to get a working x86-compatible SoC.

author: gnuarm
author_rank: Super Contributor
timestamp: May 29, 2024, 09:43:45 pm
content: Quote from: Canis Dirus Leidy on May 29, 2024, 02:31:20 pmHow large is such a CPU in an fpga?

author: langwadt
author_rank: Super Contributor
timestamp: May 29, 2024, 09:53:39 pm
content: Quote from: gnuarm on May 29, 2024, 09:43:45 pmmore like why would anyone even consider an x86 in an fpga?

author: gnuarm
author_rank: Super Contributor
timestamp: May 29, 2024, 11:45:43 pm
content: Quote from: langwadt on May 29, 2024, 09:53:39 pmBecause it will run the code from his C compiler.

author: brucehoult
author_rank: Super Contributor
timestamp: May 30, 2024, 02:48:11 am
content: Quote from: gnuarm on May 29, 2024, 11:45:43 pmA partial list of ISAs that C code can be compiled to from GCC and/or LLVM:aarch64, amd64, arc, arm32, avr, csky, hexagon, hppa, ix86, ia64, loongarch, m68k, microblaze, mips, msp430, nds32, or1k, ppc32, ppc64, riscv32, riscv64, s390, sparc, sparc64, sparcv9, thumb, xcore, xtensa.All those compilers (and usually emulators too) are just an "apt install" away on Debian-based systems (or equiv on Fedora, Arch etc).Most of them would be a better choice than x86, but in particular early arm32, riscv32, or msp430 if 16 bit is good enough.

author: gnuarm
author_rank: Super Contributor
timestamp: May 30, 2024, 04:30:00 am
content: Quote from: brucehoult on May 30, 2024, 02:48:11 amWhich of these are small enough to fit in the fpga?QuoteMaybe someone will read this and give it the attention it deserves.

author: brucehoult
author_rank: Super Contributor
timestamp: May 30, 2024, 04:49:39 am
content: Quote from: gnuarm on May 30, 2024, 04:30:00 amDepends how big the FPGA is.There is an RISC-V RV32I core that fits in 198 LUTs and 164 FF on an iCE40, or 125 LUTs and 164 FF on an Artix-7.I think the smallest and cheapest popular iCE40 boards have 3000 or 5000 LUTs, so there's plenty of room left for other things. e.g. the popular iCEBreaker has 5K LUTs and this site says it fits 10 such RV32I cores, plus a simple network joining them.https://corescore.store/An Lattice iCEstick with 384 LUTs fits 2 of these cores.Larger FPGAs can fit 10,000 SeRV cores.

author: Berni
author_rank: Super Contributor
timestamp: May 30, 2024, 05:25:35 am
content: That SERV is a neat little CPU softcore there.Does look like it would be a useful CPU for some simple control tasks in FPGAs. The size usually matters more than the speed, and this thing is packed impressively tiny. Didn't think id see CPUs with internal 1bit data paths in the modern day, but it makes perfect sense here.

author: brucehoult
author_rank: Super Contributor
timestamp: May 30, 2024, 06:10:33 am
content: Quote from: Berni on May 30, 2024, 05:25:35 amYes. It has very few gate delays so the clock can be near the FPGA's maximum (maybe 400 MHz on Artix-7?) which means even with 32 cycles for most instructions (64 for shifts and branches) it probably averages around 10 (32 bit!) MIPS at that clock speed.There is also now "QERV" which widens the data path to 4 bits and gives 3x speedup, while adding only 15% in LUTs.SeRV runs valid RV32I code, but doesn't try to do anything sensible with unimplemented opcodes -- just whatever happens happens. The same as 6502 and z80 and others of that era...

author: laugensalm
author_rank: Regular Contributor
timestamp: May 30, 2024, 03:14:25 pm
content: Quote from: Berni on May 30, 2024, 05:25:35 amThe problem with RISC-V is its suboptimal code density, and not to forget the register file which eats up at least one block ram primitive. With the 'c' (compressed instructions) extension, you get better density, but that doesn't perform well on an FPGA. I'd see the SERV rather as one of many serial CPU experiments (people have been doing this with MIPS more than 10 years ago).msp430 (I've used neo430) and ZPU are among those with best code density versus minimal LUT usage while having GCC support. Without GCC requirements, you can go even lower with funky 9 bit opcodes (this being rather FPGA specific) or code windowing (where an address line is actually part of the opcode...), or you take the mentioned Forth path through some really minimal stack machines.

author: coppice
author_rank: Super Contributor
timestamp: May 30, 2024, 03:21:46 pm
content: Quote from: laugensalm on May 30, 2024, 03:14:25 pmI think people get too hung up on code density. I've spent years around people experimenting with code density, and getting excited about small increases. When you point out how little real world code for ARMs uses THUMB instructions they sulk.

author: ataradov
author_rank: Super Contributor
timestamp: May 30, 2024, 03:48:17 pm
content: In FPGAs and soft cores code density matters. If you are using soft cores for basic control tasks, then you are likely running out of BRAMs, and those are usually not great to waste.

author: langwadt
author_rank: Super Contributor
timestamp: May 30, 2024, 05:56:54 pm
content: Quote from: ataradov on May 30, 2024, 03:48:17 pmyeh, that's the problem with softcores, if you look at an MCU die almost all of it is memory, and an FPGA is a very expensive way to buy memory

author: langwadt
author_rank: Super Contributor
timestamp: May 30, 2024, 06:30:20 pm
content: Quote from: coppice on May 30, 2024, 03:21:46 pmdepends on what ARM, cortex-m is only thumb(-2)with slow memory like the flash usually is on an MCU it can also help with speed

author: asmi
author_rank: Super Contributor
timestamp: May 31, 2024, 02:20:39 pm
content: Quote from: ataradov on May 30, 2024, 03:48:17 pmJust about all FPGAs load their bitstream from QSPI flash, and almost always there is a leftover space which can be used to store application code. The only "cost" here is a small component to access QSPI flash, and since the only thing it requires is readonly access, it can be very simple as all it needs to do is issue a read command with start address where application is stored, copy it to some external memory, and transfer control to it. AMD/Xilinx even provides an out-of-box solution for this in form of SREC bootloader. And in rare case when FPGA doesn't have any external memory, you can run the code straight from QSPI via XIP.

author: bson
author_rank: Unknown
timestamp: June 12, 2024, 08:29:19 pm
content: Quote from: rstofer on January 18, 2020, 08:39:23 pmThere's not much compelling reason to learn the DEC OSes, other than from a system design perspective. Of them, RSX-11M/M+ is by far the most interesting; it's an asynchronous real-time executive without threading, but with (never shipped with) SMP support. The second most interesting is RSTS/E with its runtime system (RTS) model, which is basically an OS emulation layer, with emulators for other DEC OSes (and a few other specialized things; when I was in high school we created a LISP RTS for RSTS/E). The RTSes handled things like command parsing and syscall translation to native RSTS/E. It was a pretty nice timesharing system actually (for the day) that came with a native BASIC RTS. You could do things like develop software targeting dedicated RSX-11M (or S) systems without things like virtual memory (on the target), on the timeshare system, then often just link it for the target and run it there. (Linking was required without an MMU to actually relocate the program for the target system.) The linker, the RSX task builder (TKB) was much more than just a linker.Of course completely obsolete today. It was practical and quite excellent for the days though, and I think worth studying for anyone interested in system design. (Much of RSX also came with source code that was compiled for a specific system during the install process - and later to change system options.)By comparison I personally (just me) think BSD is a big shrug... it's just an old, very primitive Unix.

author: Berry Straw
author_rank: Newbie
timestamp: June 17, 2024, 02:28:32 pm
content: Something like this maybe?https://x.com/BrunoLevy01/status/1795102632438038768

author: trossin
author_rank: Contributor
timestamp: June 17, 2024, 07:36:52 pm
content: I’m not sure if this was said but instead of creating your own instruction set, reinvent the wheel and design your own implementation of a vintage processor. This way a C compiler will already exist. You can make it fun by amping up the implementation by adding multi-level caching, out of order execution and branch prediction logic. A killer 68000 would be fun as it at least has a large address space compared to a 6502.Years ago I created a cycle and speed accurate hardware emulator of a 1970s vintage 1802 processor using a PIC microprocessor all in assembler. That was a fun project. I also wrote a toy C compiler for it which I’ll admit was painful.

author: brucehoult
author_rank: Super Contributor
timestamp: June 17, 2024, 11:27:02 pm
content: Quote from: trossin on June 17, 2024, 07:36:52 pmAbsolutely the path of least resistance. But vintage processors are often not well supported by modern compilers -- or just are very difficult to support. It's easier to implement RISC-V RV32I than 6502. Or Arm, for that matter, but you can publish your RISC-V CPU without getting sued.

author: bson
author_rank: Unknown
timestamp: August 09, 2024, 09:18:48 pm
content: You could grab an older version of gcc and add a machine description (.md) and other bits and pieces needed for your target. You'd also need a version of binutils and do the same for gas since older gcc's generate assembly that needs to be assembled. But presumably you want an assembler anyway. You also need to add support to libbfd and few other libraries. The most elementary .md for gcc is pretty straightforward (I added several in the 90s when I worked on those versions of gcc on the GNU Project at FSF, just for testing purposes, using completely invented architectures, for example with only subtraction, complement, and increment, but no addition so it would be forced to exercise my changes), and then you can address obvious shortcomings as they crop up and bother you. This is assuming you're inventing a GPR-based architecture with linear memory; anything else and C is not going to be a good option.

author: DiTBho
author_rank: Super Contributor
timestamp: August 09, 2024, 10:34:58 pm
content: Quote from: rstofer on January 18, 2020, 06:54:47 pmmyC has been 8 years in the making, there is no optimization layer yet and the machine layer only includes MIPS32 and MIPS5++ (prototype).I personally spent some time on myC too to do some personal development and research and see what could be done to improve C.Not much, I tried and... honestly, I tried so many ideas in the last 8 years, almost all of them miserably failed, except the latest approach that is giving me satisfaction, but not so much if we consider the generated code.I think it's basically a matter of trade-offs, but finding the right balance in a C compiler, written from scratch and mutated, or simply cloned and retargeted, always requires experience and a lot of time and dedication.Does it make sense? It depends, but if the goal is to run Doom, then I think it's better to take a risc-v core, a { binutils, gcc, gdb, musl } toolchain, and digest them as is.

author: DiTBho
author_rank: Super Contributor
timestamp: August 09, 2024, 10:43:44 pm
content: Quote from: trossin on June 17, 2024, 07:36:52 pmThis remembers me when I tried to add M56000 to gcc-v2.95It's an old Motorola DSP.There are no C compilers for it.563xx has a few, 56000 has none.

author: DiTBho
author_rank: Super Contributor
timestamp: August 09, 2024, 10:50:56 pm
content: Quote from: gnuarm on May 25, 2024, 01:42:59 pmGameDuino-v1. Basically a Forth-CPU on a Spartan3-250.(v2 is completely different)