Lazarus
Programming => Operating Systems => Embedded => Topic started by: SymbolicFrank on May 28, 2019, 12:26:58 am
-
The fpc specifications require at least 8 MB of memory, and 80 MB of storage. Would it be possible to make a very minimal build that would run on an ARM Cortex microcontroller? Say, at most 256 kB of memory and 1 MB of storage. How would that look like? An old build?
If that is not possible, what else could be done?
It wouldn't have an OS, so what other requirements (memory management, libraries and such) would there be?
The goal is to be able to compile and link small (Object) Pascal units and programs, at most a few kilobytes each. A subset is fine, objects would be nice. A bit like LUA.
If possible, is there some documentation somewhere, or do I download the source and try to figure it out myself?
-
I think those values are very old (like FPC 1.0.x and dos). You can simply start debugging a typical job and try to avoid and minimize buffers.
But 256kb is awfully little, and you probably also need to run AS and LD after. Doesn't seem easy to me.
-
The compiler binary itself is already 3MB. The compiler is not designed for minimal size, but for maximal maintainability and portability. This means it contains lots of abstractions, which is bad both for code size and memory use.
I don't think it's possible to adapt the compiler to fit in the constraints you mention.
-
Would it be possible to make a very minimal build that would run on an ARM Cortex microcontroller? Say, at most 256 kB of memory and 1 MB of storage.
Running FPC on 256Kb/1Mb is not a realistic request. Since I don't think cross compilation is what you're after, maybe building your own pascal compiler or interpreter could satisfy you? You might even try to get away with just adapting and cross compiling PascalScript or some other simpler Pascal interpreter and then building around it. Lot's of work, but result would be similar to existing MicroPython or Lua...
-
Maybe the pico pascal compiler (https://github.com/paulherman/ppc) can help you.
If you could get along with old style iso pascal without objects, the p5 pascal compiler might do a job.
-
A tough challenge. Some ideas:
- remove compiler messages and help (~ 80kB)
- drop debug info support (this will probably shave off a few kB)
- remove unicode support in compiler[\li]
- remove multiple dialect support (macpas/fpc/delphi/objfpc/iso) and only support a single dialect (probably complicated, I think these dialect checks are sprinkled over several units)
I'll speculate that this will drop the compiler size closer to 2 MB in size.
In embedded you have to provide build-in file system support of some kind and memory management. At least there is a lightweight heap manager in RTL. Then (as marcov mentioned) you need binutlis such an assembler and linker. Not sure this is available, so one may have to include an embedded linker in the compiler.
-
If you could get along with old style iso pascal without objects, the p5 pascal compiler might do a job.
A p5 compiler that can be compiled by FPC is available from https://github.com/tangentstorm/pascal/tree/master/p5 (https://github.com/tangentstorm/pascal/tree/master/p5).
-
8 MB RAM is too small for modern compilers. Maybe it's better to use some other small Pascal compilers or create one new. It will depends on what features you want to support in the compiler. OOP compilers are complex but classic Pascal compilers are smaller.
-
(I can remember my first attempt at porting pre 1.0 FPC to FreeBSD. The year was 1998, and the idea was to just make cycle with a target linux, but then on a FreeBSD system). The non production FreeBSD system was an old 486 with 8MB, and a 32MB swap.
After 6 hours compiling it bombed out with a linking error, sigh. Slow porting it is :)
-
I knew I would find it in the end. You can take a look for inspiration at this a p-code Pascal running on AVR MEGA163:
https://community.atmel.com/projects/pchip
You might also examine these p-code related links:
https://gist.github.com/r-lyeh-archived/0af42b2788bb75219061
https://www.slideshare.net/Sandeep_Rv/p-code
http://www.textfiles.com/bitsavers/pdf/stanford/sel_techReports/TN164_A_Pascal_P-Code_Interpreter_for_the_Stanford_Emmy_Sep79.pdf
https://homepages.cwi.nl/~steven/pascal/
https://scara.com/~schirmer/o/pcodevm/
https://en.wikipedia.org/wiki/P-code_machine
-
Thanks for the suggestions. I'll go through them.
Why would the fpc.exe be 3 MB? On my PC it's only 131 kB. Symbols?
I want to try and make an "interactive" microcontroller, so I can have a dashboard and change functions while it is running. It isn't meant as a replacement for a PC, like a Raspberry Pi, (all communication through USB / Ethernet), but as an interactive way to build your circuit.
The most common MCU's have 64 kB of Flash and 20 kB of RAM. That's not much. The largest practical MCU's are like this: https://uk.farnell.com/stmicroelectronics/nucleo-l432kc/dev-board-nucleo-32/dp/2580786 (https://uk.farnell.com/stmicroelectronics/nucleo-l432kc/dev-board-nucleo-32/dp/2580786). It has 256 kB of Flash and 64 kB of RAM.
There are ARM MCU's with 2 MB Flash and 1 MB RAM on-board, but they are around 4 cm2 in size and have 100+ pins, so they're hard to fit on a bread-board. Adding external Flash and RAM just to get the compiler running would be counter-productive and make it reasonably expensive.
My options for programming would be:
1. External compiler. Possible, but not interactive enough. A dashboard is like a debugger running on the device.
2. Assembler. Doable, but too low-level.
3. Interpreter: Slow but doable. But Pascal, no Basic or whatever. It would mess up your timing and be unusable for handling interrupts. Meh.
4. Tiny compiler, with the code split in units / objects and interactive debugging. Actually, something like Turbo Pascal 1.0 would work.
Optimally, the program is stored in P-code, for example like a ZX_Spectrum did it. It might be interesting to see if I could make a parse tree editor. And units / objects are loaded and linked in memory on demand. Objects would simplify memory management as well. Ok, that's a lot of work. But with a lot of re-use probably doable.
-
Why would the fpc.exe be 3 MB? On my PC it's only 131 kB. Symbols?
fpc(.exe) is not the compiler, it does some checks and set-up, and calls e.g. ppcx64 which is the "real" compiler.
-
Ah, thanks. That size was the first thing I checked. It looked small, but not impossible for a console application. I should have looked better.
I'll check all the suggestions first.
-
That P-5 compiler documentation was interesting.
After reading the above and thinking about it, it seems to me, that the goal is to store the program as compact as possible, to minimize overhead. And if I do that by analyzing it, the parsing is already done.
Store everything that is not a constant, variable or set / array / list as a record (minimalist object), try to simplify expressions as much as possible while retaining object names and use a JIT for code generation.
Most everything else is either operating system or user interface. And I think it's probably simpler to just write everything myself, than to try and reuse as much existing code as possible. Although the source code of an ARM assembler would be useful. For the OS I'm going to look at RTOS, but probably I'll do that myself as well.
-
I was trying doing something similar but running in a MOS6502. The idea is to make a compiler/interpreter running in a Operative System writen using the same compiler.
Currently I'm improving my 6502 compiler and I'm experimenting building a simple bootstraping compiler.
-
So tell me what current processors/ min boards use a 6502 instruction set?
I made an assembler/IDE with the Pet/CMD/128 etc..
-
So tell me what current processors/ min boards use a 6502 instruction set?
My compiler is aim to work in differents 6502 systems, but my tests are in a Commodore 64.
I made an assembler/IDE with the Pet/CMD/128 etc..
Good. I've included complete support for ASM blocks in my compiler.
-
I explored the options for the initial IDE to use:
1. Arduino: far too simple. Nice if all you want is a short, endless loop. But everything is preconfigured and runs out of the box.
2. ARM development IDE's: Either very expensive or Eclipse variants. Your only real choice is C or C++. Assembler is barely supported. And a minimal startup configuration is spread out over many header and source files. I spend about a day getting such a minimalist development environment together. The debugging works great.
3. Lazarus: far superior to Eclipse. I can use Pascal (but not assembler). And now with a new embedded platform choice! Well, I didn't get it to work yet, and I would have to make a new profile for my test CPUs, or use different ones. Spend a week or so researching and fixing that? I might get the compiling, linking and flashing to work using only command-line tools, but most info I could find seem to be outdated.
Decisions, decisions.
Anyway, it seems my best bet would be to translate the minimal C startup code to assembly, write an assembler/disassembler in assembly, a pascal compiler in pascal and have them compile themselves.