Re: [fpc-devel] Review of AVR patch for bug 31925
implementing 8*8 bit multiplications as library functions is certainly one way to cope with the absence of mul/mulsu instructions in the "basic" avr subarchitectures, and the resultint compiler error message when confronted with any source code resulting in such a multiplication. The question is, if that is the most reasonable way to do it, or if it would be simpler to have the compiler directly insert the required compare/add/shift sequence. This should be answered by someone with a very good knowledge of the AVR code generator. Am 22.09.2017 um 12:28 schrieb Christo: On Fri, 2017-09-22 at 07:10 +0200, Christo wrote: On Wed, 2017-09-20 at 12:36 +0200, Karoly Balogh (Charlie/SGR) wrote: A complication I've noted is that enabling overflow checking doesn't call the fpc_mul_byte_overflow function (as the naming convention suggested), rather the generated code calls fpc_mul_byte and then check the carry flag to determine whether an overflow occurred. Since the function in generic.inc is plain pascal code there is no guarantee that the carry flag will be set if an overflow should have occurred. I assume that at a higher level the code generator assumes that a hardware MUL instruction _will_ be used, leading to incorrect overflow detection logic if a software helper is used. A similar situation exist for the current 16 bit software MUL case with overflow checking. Any pointers on where to start looking to try and adapt the overflow checking code generation? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Specific RTL for embedded target
Simon, what you are referring to is mostly not the RTL (which is a standardized set of routines necessary to "make pascal work"). but are device drivers that provide a link between the RTL and the underlying hardware, tasks that in a non - embedded environment are performed by the operating system. An example: the procedure "write / writeln" is part of the RTL. it does all the formatting, calls conversion routines where necessary (from numerical formats to string), and so on - but finally passes the formatted sequence of characters to the operating system's file I/O, which forma an intermediate layer, and finally calls the appropriate device drivers (serial, console, disk, ). I completely agree with you that such a library would be highly desirable, but it is a different thing than the RTL. One exception: string functions, these are part of the RTL. for the AVR, I am working on a unit system, that is mainly writen in assembler. best regards, Georg Am 11.11.2015 um 18:06 schrieb Simon Ameis: Hello, does anyone work on a library (embedded RTL) for basic embedded microcontroller units (MCU) like AVR or ARM? I think, there should be a stable interface along different MCUs for accessing various hardware interfaces. * MCU compatible/optimized string functions * I2C * SPI * GPIO * Analog Inputs/Outputs * PWM * UART * Timer * Watchdog timers These topics are much more dependant on the individual MCU families. It would be great to have a cross MCU API though. * MCU setup * Power Management As there are some libraries out there on the net, they could inspire the design of the embedded RTL. Are there any concerns on translating one library as long as it has a less restrictive license than modified LGPL used by the default RTL (e.g. BSD license)? Kind Regards Simon Ameis ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] avr: Cannot link example project
Anton, Which version (build) of the compiler / rtl did you use? This looks like an error that should have been fixed some time ago. BR, Georg Am 06.05.2015 09:01, schrieb Anton Kavalenka: Dear FPC-All! I've tried to compile hello-world-through-UART example (in attacment) for Atmega128 and got the following: /usr/local/lib/fpc/3.1.1/ppcrossavr a.pas -WpATMEGA128 -al Free Pascal Compiler version 3.1.1 [2015/05/05] for avr Copyright (c) 1993-2015 by Florian Klaempfl and others Target OS: Embedded Compiling a.pas Assembling a Linking a /usr/local/lib/fpc/3.1.1/units/avr-embedded/rtl/atmega128.o: In function `_START': atmega128.pp:(.init.n_atmega128_ss__fpc_start+0x2): relocation truncated to fit: R_AVR_13_PCREL against symbol `Int00Handler' defined in .text.n_atmega128_ss_default_irq_handler section in /usr/local/lib/fpc/3.1.1/units/avr-embedded/rtl/atmega128.o atmega128.pp:(.init.n_atmega128_ss__fpc_start+0x4): relocation truncated to fit: R_AVR_13_PCREL against symbol `Int01Handler' defined in .text.n_atmega128_ss_default_irq_handler section in /usr/local/lib/fpc/3.1.1/units/avr-embedded/rtl/atmega128.o atmega128.pp:(.init.n_atmega128_ss__fpc_start+0x6): relocation truncated to fit: R_AVR_13_PCREL against symbol `Int02Handler' defined in .text.n_atmega128_ss_default_irq_handler section in /usr/local/lib/fpc/3.1.1/units/avr-embedded/rtl/atmega128.o atmega128.pp:(.init.n_atmega128_ss__fpc_start+0x8): relocation truncated to fit: R_AVR_13_PCREL against symbol `Int03Handler' defined in .text.n_atmega128_ss_default_irq_handler section in /usr/local/lib/fpc/3.1.1/units/avr-embedded/rtl/atmega128.o atmega128.pp:(.init.n_atmega128_ss__fpc_start+0xa): relocation truncated to fit: R_AVR_13_PCREL against symbol `Int04Handler' defined in .text.n_atmega128_ss_default_irq_handler section in /usr/local/lib/fpc/3.1.1/units/avr-embedded/rtl/atmega128.o atmega128.pp:(.init.n_atmega128_ss__fpc_start+0xc): relocation truncated to fit: R_AVR_13_PCREL against symbol `Int05Handler' defined in .text.n_atmega128_ss_default_irq_handler section in /usr/local/lib/fpc/3.1.1/units/avr-embedded/rtl/atmega128.o atmega128.pp:(.init.n_atmega128_ss__fpc_start+0xe): relocation truncated to fit: R_AVR_13_PCREL against symbol `Int06Handler' defined in .text.n_atmega128_ss_default_irq_handler section in /usr/local/lib/fpc/3.1.1/units/avr-embedded/rtl/atmega128.o atmega128.pp:(.init.n_atmega128_ss__fpc_start+0x10): relocation truncated to fit: R_AVR_13_PCREL against symbol `Int07Handler' defined in .text.n_atmega128_ss_default_irq_handler section in /usr/local/lib/fpc/3.1.1/units/avr-embedded/rtl/atmega128.o atmega128.pp:(.init.n_atmega128_ss__fpc_start+0x12): relocation truncated to fit: R_AVR_13_PCREL against symbol `Int08Handler' defined in .text.n_atmega128_ss_default_irq_handler section in /usr/local/lib/fpc/3.1.1/units/avr-embedded/rtl/atmega128.o atmega128.pp:(.init.n_atmega128_ss__fpc_start+0x14): relocation truncated to fit: R_AVR_13_PCREL against symbol `Int09Handler' defined in .text.n_atmega128_ss_default_irq_handler section in /usr/local/lib/fpc/3.1.1/units/avr-embedded/rtl/atmega128.o atmega128.pp:(.init.n_atmega128_ss__fpc_start+0x16): additional relocation overflows omitted from the output a.pas(22,25) Error: Error while linking a.pas(22,25) Fatal: There were 1 errors compiling module, stopping Fatal: Compilation aborted regards, Anton Kavalenka ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] avr port: rtl, unit system
Hello, I started to implement parts of the rtl system unit for avr in assembler. First results are encouraging: fpc_move takes 29 opcodes compared to 104 of the Pascal version already optimized for the platform, and 23:150 for fpc_mul_word. Of course, I want to be as efficient as possible in this task, and first convert routines that are either -called often, to reduce execution time, or -linked into most binaries, to reduce code size. I made my own priority list, starting with the essential string routines and arithmetic helpers, but due to lack of experience I certainly overlooked things or overestimated others. So, question to everybody: Which are according to your experience / opinion the library routines that profit most from being implemented in assembler, considering an embedded environment? (so, nothing about file I/O, system call wrappers, etc.) Thanks for a lot of answers Georg --- Este email foi escaneado pelo Avast antivírus. http://www.avast.com ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] multiple accounts on bugtracker
This is certainly the wrong place ... It looks like I have multiple accounts on bugtracker, and they are not all accessible. Whom can I contact to clean up this mess? regards, Georg --- Este email foi escaneado pelo Avast antivírus. http://www.avast.com ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Embedded Strings on nRF51-DK
Paul, a few comments from somebody who is not a compiler developer, but who very recently started to get fpc running for another embedded platform, the avr. 1) you write somewhere that you ported things from c, and your examples start as function main: integer ... which looks to me exactly like int main(). In pascal, there is no need to declare a function main. it is created automatically by the runtime system and contains the begin .. end block of your pascal program. In an embedded environment it is called immediately after some essential initialization (stack pointer, zeroing menory etc.), and if it returns, control goes to a system halt procedure. 2) if you build your crosscompiler with the command make clean all OS_TARGET=embedded CPU_TARGET=my_cpu make will not only build you a compiler but also a basic rtl (without, for example, file handling, as that needs an underlaying operating system), but which includes things like simple string handling. What this system includes and what not is controlled by the file fpcbase/rtl/embedded/rtl.cfg. For the beginning leave the default, minimal settings. 3) avoid ansistrings. They need heap management which is probably not available in the basic system, and consume much more resources than short strings. 4) how good (in the sense of efficient, short and fast execution code) or bad the rtl thus constructed is depends on how much work has already gone into porting fpc to the cpu / system combination you use. The rtl building process is using a clever sequence of conditional compiles to check if a certain function has already been implemented cpu and/or opsys specific, and if that is not the case, falls back to a generic procedure written in pascal that does the job, however not always in the most elegant way. The good part is, that from the beginning you will have a rtl that works. 5) unlike C, the fpc compiler depends on the existence of at least a minimal rtl (unit system), even if you don't call library functions explicitely. There are actually a lot of routines in system.pp and it's include files that are declared with the qualifier compilerproc which makes them invisible for the application program. Calls to these functions, however, appear, inserted directly by the compiler 6) there is no need to mess around with linker scripts etc. As long as you stay inside the pascal world, i.e. write your application as a pascal program that can (or not) use several units, and do any necessary assembler programming using fpc's inline assembler, fpc will take care of the linking process. Either completely behind the scene, or, if you define so, by creating a linker script you can use. And even if you use external references (third party libraries, for example), if they are referenced by correctly declared pascal external functions, this should work. 7) the rtl unit system will be (smart-)linked automatically to your program, every other rtl unit has to be requested explicitely by a uses clause if their functionality is needed. 8) does your program have a program, i.e. a main file that adheres to the syntax program myprog declarations... begin statements end. I have only seen a unit main, which for the fpc system is nothing more than one of probably many units, but which does not tell the compiler to link to the rtl (to be precise, to the unit system). The program does exactly that. your examples look to me as if you are following your C habits, just writing in pascal. If that's correct - don't do it. Most likely, the problems you are encountering will dissapear as soon as you just let fpc and the basic rtl do their jobs. Do the following: - build a compiler and rtl using OS_TARGET=embedded and CPU_TARGET whatever is closest to your actual cpu, which seems to be some arm variety. - write your main as the begin .. end block of a program - let fpc take care of the linking. I hope what I wrote helps a little and does not bore too much, Georg Am 16.04.2015 um 15:29 schrieb Jeppe Johansen: On 04/16/2015 12:49 PM, Paul Michell wrote: I assume this is because string handling support is not included in the embedded RTL generated with the compiler, or that I am not linking the right object files if I need to do this by hand? What would be the best way to enable string handling? Even short string handling would make FPC far more preferable to C for me for embedded work. You would make it a whole lot easier for yourself if you just used the Embedded target and added an actual controller type for that specific microcontroller. Then you wouldn't need to play around with linker scripts and manually including and trimming RTL files. Adding the controller type is about 5-10 lines of code. Then the RTL unit can be a stub for now which basically just initializes .data and .bss. If you have the name of the controller I can add it?
[fpc-devel] Florian is reading my thoughts....
and fixed the next issue I was about to report, the fact that ppcrossavr allocated 4 bytes in the stack frame for every variable, even if it needed only one. That's history, THANKS! (not only for that, but forall the work you have recently put into the avr compiler). There is a small leftover from that issue, and I don't know if that's on purpose or still undesired: now (30599) 2 bytes more than needed are assigned. Georg. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] avr port, feedback to changes until 30549
Florian, presently the make cycle aborts when compiling the compiler. In cgcpu.pas there ist a comment (code not working yet), line 770, inside a comment which causes an error. after fixing that, both the compiler and the rtl are built without problems. So, apparently, the changes you made to take pressure off the register allocator work. Question: where is EXCLUDE_COMPLEX_PROCS defined? regards, Georg ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] avr port: avrsim.pp
A few days ago the file avrsim.pp - startup code for an avr simulator appeared. Has anybody actually run (and debugged) code produced with fpc on an avr simulator? If yes, a few hints about how the whole thing is set up would be highly appreciated. Thanks, Georg ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] building ppcrossavr, internal error 200309041
Hello, As during the last days a lot of changes occurred to files related to the avr port - btw., thanks to everybody! - I wanted to build the latest SVN version (30489). Doing make clean all OS_TARGET=embedded CPU_TARGET=avr, the compiler builds, but when compiling system.pp, compilation aborts with sstrings.inc(835,1) Fatal: Internal error 200309041. A few days ago, on 29.3., the make went through without errors. I had this problem before, and changing the optimization level changes the behavior. If I hand compile system.pp with -O1, the error in sstrings.inc dissapears, but it appears as text.inc(1232,1) Fatal: Internal error 200309041. I also had this error before, and as a workaround to at least compile system.pp I disabled textio. That way at least I get a system.o to work with, but somewhere there is a problem. I am a bit reluctant to file a bug report about this as apparently it changes between SVN versions. Another question: is it true that the compiler build cycle needs the last stable version (2.6.4) to start, and won't work with a newer one (3.1.1)? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] avr-port: register usage and calling convention?
Hi, I am about to implement some rtl procedures in avr - assembler, and of course register usage and calling conventions are important for that. The fpc wiki says concerning avr, It uses the GCC AVR tool chain and will be compatible with GCC regarding calling conventions etc.. That would be passing arguments in registers r25 - r8 downwards (first argument in r24, r25 if 16 byte, 2nd below that etc.). High bytes are in high and low bytes in low register no. Function results are returned in r22 - r25 (32byte), r24-r25 (16 byte). According to GCC documentation, R0, R18-R27, R30, R31 are call used, R 2-R17, R28 and R29 are call saved. R1 has always to be 0. Actual code produced by the compiler looks different. It is the same sequence of arguments (first in highest registers, second below that ...), but the byte order is reversed, lowest byte in highest register no. After noting this discrepancy, I am of course unsure about the whole matter. Could somebody tell me what convention is actually used by the compiler? A word to register R1: it shall be 0 at all times according to GCC specs. In some occasions, the compiler uses this to set other registers to 0, by MOV reg, R0. On other occasions the compiler uses the CLR Reg instruction (which is actually a pseudo opcode that translates to EOR reg, reg). On the other hand, R0 and R1 are used by the MUL / MULS / MULSU instructions to return the multiplication result. Forgetting to clear R0 again after a multiplication (i.e. in an assembler routine) will thus lead to errors at some later time. As long as the MOV is not used because it does not change any status flags, It might be a good idea if the compiler always used the CLR instruction. Thanks in advance for some info on the register stuff, Georg ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] avr-port: register usage and calling convention?
Thanks, Florian. I will dig a bit deeper and eventually file a report. Georg Am 31.03.2015 um 03:53 schrieb Florian Klämpfl: Am 31.03.2015 um 02:14 schrieb Georg Hieber: Hi, I am about to implement some rtl procedures in avr - assembler, and of course register usage and calling conventions are important for that. The fpc wiki says concerning avr, It uses the GCC AVR tool chain and will be compatible with GCC regarding calling conventions etc.. That would be passing arguments in registers r25 - r8 downwards (first argument in r24, r25 if 16 byte, 2nd below that etc.). High bytes are in high and low bytes in low register no. Function results are returned in r22 - r25 (32byte), r24-r25 (16 byte). According to GCC documentation, R0, R18-R27, R30, R31 are call used, R 2-R17, R28 and R29 are call saved. R1 has always to be 0. Actual code produced by the compiler looks different. It is the same sequence of arguments (first in highest registers, second below that ...), but the byte order is reversed, lowest byte in highest register no. After noting this discrepancy, I am of course unsure about the whole matter. Could somebody tell me what convention is actually used by the compiler? It is supposed to the use gcc one. It is simply a bug if it differs. A word to register R1: it shall be 0 at all times according to GCC specs. In some occasions, the compiler uses this to set other registers to 0, by MOV reg, R0. On other occasions the compiler uses the CLR Reg instruction (which is actually a pseudo opcode that translates to EOR reg, reg). On the other hand, R0 and R1 are used by the MUL / MULS / MULSU instructions to return the multiplication result. Forgetting to clear R0 again after a multiplication (i.e. in an assembler routine) will thus lead to errors at some later time. As long as the MOV is not used because it does not change any status flags, It might be a good idea if the compiler always used the CLR instruction. I'll try to remember this :) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
