Recent

Author Topic: light pascal  (Read 3399 times)

Dimitrios Chr. Ioannidis

  • Jr. Member
  • **
  • Posts: 90
    • Nephelae
Re: light pascal
« Reply #45 on: January 13, 2020, 09:46:02 pm »
Hi,

  AFAIU, even Atmel in AVR200: Multiply and Divide Routines for unsigned  8-bit  division ( optimized for size) report "Code Size (Words) 14" for their algorithm ....

  Also someone more experienced than me, said "...scaling calculations so that divisions are done with powers of 2 are popular on 8 bitters because shifts are much simpler than division." .

  You'll notice it if you change the value 17 with 32, 64 etc ...

Code: Pascal  [Select]
  1. Free Pascal Compiler version 3.3.1 [2020/01/12] for avr
  2. Copyright (c) 1993-2019 by Florian Klaempfl and others
  3. Target OS: Embedded
  4. Compiling tt.lpr
  5. tt.lpr(11,8) Warning: Variable "x" does not seem to be initialized
  6. Assembling tt
  7. Linking tt
  8. 12 lines compiled, 0.2 sec, 218 bytes code, 0 bytes data
  9. 1 warning(s) issued




  regards,
« Last Edit: January 13, 2020, 10:17:14 pm by Dimitrios Chr. Ioannidis »
Dimitrios Chr. Ioannidis
http://www.nephelae.eu

ccrause

  • Full Member
  • ***
  • Posts: 222
Re: light pascal
« Reply #46 on: January 14, 2020, 01:23:34 pm »
Whether it is acceptable or not does not matter. div handling with all it's infrastructure needed in object pascal is that big. FPC generates an ldi, three moves and a call for the div.
8< ...

I agree that the safety of using Pascal should not be sacrificed, but I would like to suggest that more compact error handling could be implemented for AVR, see e.g. the suggestion in issue 35754.  Basically, remove exception raising code, since exception handling support is not enabled anyway.

julkas

  • Hero Member
  • *****
  • Posts: 520
  • KISS principle / Lazarus 2.0.6 / FPC 3.0.4
Re: light pascal
« Reply #47 on: January 14, 2020, 02:30:16 pm »
Whether it is acceptable or not does not matter. div handling with all it's infrastructure needed in object pascal is that big. FPC generates an ldi, three moves and a call for the div.
8< ...

I agree that the safety of using Pascal should not be sacrificed, but I would like to suggest that more compact error handling could be implemented for AVR, see e.g. the suggestion in issue 35754.  Basically, remove exception raising code, since exception handling support is not enabled anyway.

rtl/embedded/system.cfg -
Code: Text  [Select]
  1. # does not require extra memory, neither code nor data
  2. # in programs not using e. g. writeln based I/O which is the common case for AVR
  3. #ifdef CPUAVR
  4. -SfOBJECTS
  5. -SfEXCEPTIONS
  6. -SfCLASSES
  7. -SfRTTI
  8. # AVR6 has normally more memory, so enable more functions
  9. #ifdef CPUAVR6
  10. -SfANSISTRINGS
  11. -SfWIDESTRINGS
  12. -SfDYNARRAYS
  13. -SfTHREADING
  14. -SfVARIANTS
  15. -SfOBJECTS
  16. -SfCOMMANDARGS
  17. -SfRANDOM
  18. -SfRESOURCES
  19. #endif
  20. #endif
So exception handling enabled or disabled?
procedure mulu64(a, b: QWORD; out clo, chi: QWORD); assembler;
asm
  mov rax, a
  mov rdx, b
  mul rdx
  mov [clo], rax
  mov [chi], rdx
end;

ccrause

  • Full Member
  • ***
  • Posts: 222
Re: light pascal
« Reply #48 on: January 14, 2020, 04:12:30 pm »
Whether it is acceptable or not does not matter. div handling with all it's infrastructure needed in object pascal is that big. FPC generates an ldi, three moves and a call for the div.
8< ...

I agree that the safety of using Pascal should not be sacrificed, but I would like to suggest that more compact error handling could be implemented for AVR, see e.g. the suggestion in issue 35754.  Basically, remove exception raising code, since exception handling support is not enabled anyway.

rtl/embedded/system.cfg -
Code: Text  [Select]
  1. # does not require extra memory, neither code nor data
  2. # in programs not using e. g. writeln based I/O which is the common case for AVR
  3. #ifdef CPUAVR
  4. -SfOBJECTS
  5. -SfEXCEPTIONS
  6. -SfCLASSES
  7. -SfRTTI
  8. # AVR6 has normally more memory, so enable more functions
  9. #ifdef CPUAVR6
  10. -SfANSISTRINGS
  11. -SfWIDESTRINGS
  12. -SfDYNARRAYS
  13. -SfTHREADING
  14. -SfVARIANTS
  15. -SfOBJECTS
  16. -SfCOMMANDARGS
  17. -SfRANDOM
  18. -SfRESOURCES
  19. #endif
  20. #endif
So exception handling enabled or disabled?

Let me rephrase: According to the Wiki: To enable the RTL to raise exceptions instead of generating runtime errors, use the SysUtils unit in your program.
SysUtils unit is not included in the list of units for AVR in Makefile => there is no point currently to check if an exception should be raised for AVR in the RTL error handling code.

Of course the easiest solution right now to reduce the size of the RTL error handling portion of the code is to comment out -SfEXCEPTIONS in system.cfg and rebuild RTL.

Laksen

  • Hero Member
  • *****
  • Posts: 637
    • J-Software
Re: light pascal
« Reply #49 on: January 14, 2020, 05:33:44 pm »
Ahh, yeah div still pulls in the exception handling. I actually thought that had been changed, as in have generic *_checkoverflow versions that do division by zero checking. When dividing by a positive non-zero constant there can never be overflows, and this is usually what is used on AVR (divide/mod by 10 for int<>string conversion)

julkas

  • Hero Member
  • *****
  • Posts: 520
  • KISS principle / Lazarus 2.0.6 / FPC 3.0.4
Re: light pascal
« Reply #50 on: January 14, 2020, 05:53:47 pm »
Ok. I will rebuild cross compiler and report results. Thanks.
procedure mulu64(a, b: QWORD; out clo, chi: QWORD); assembler;
asm
  mov rax, a
  mov rdx, b
  mul rdx
  mov [clo], rax
  mov [chi], rdx
end;

julkas

  • Hero Member
  • *****
  • Posts: 520
  • KISS principle / Lazarus 2.0.6 / FPC 3.0.4
Re: light pascal
« Reply #51 on: January 18, 2020, 02:10:23 pm »
After disabling
-SfEXCEPTIONS
-SfCLASSES
in rtl/embedded/system.cfg code size reduced by 1K -
Code: Text  [Select]
  1. 2057 lines compiled, 0.5 sec, 7174 bytes code, 388 bytes data
  2.  
« Last Edit: January 18, 2020, 02:17:00 pm by julkas »
procedure mulu64(a, b: QWORD; out clo, chi: QWORD); assembler;
asm
  mov rax, a
  mov rdx, b
  mul rdx
  mov [clo], rax
  mov [chi], rdx
end;

julkas

  • Hero Member
  • *****
  • Posts: 520
  • KISS principle / Lazarus 2.0.6 / FPC 3.0.4
Re: light pascal
« Reply #52 on: January 19, 2020, 12:16:17 pm »
Strange output. I have disabled  CLASSES, EXCEPTIONS - 
Code: Text  [Select]
  1. $ ppcrossavr.exe -i
  2. Free Pascal Compiler version 3.3.1
  3.  
  4. Compiler date      : 2020/01/18
  5. Compiler CPU target: avr
  6.  
  7. Supported targets (targets marked with '{*}' are under development):
  8.   embedded: Embedded
  9.  
  10. Supported CPU instruction sets:
  11.   AVR1,AVR2,AVR25,AVR3,AVR31,AVR35,AVR4,AVR5,AVR51,AVR6
  12.  
  13. Supported FPU instruction sets:
  14.   NONE,SOFT,LIBGCC
  15.  
  16. Supported inline assembler modes:
  17.   STANDARD
  18.   GAS
  19.  
  20. Recognized compiler and RTL features:
  21.   HEAP,INITFINAL,RTTI,CLASSES,EXCEPTIONS,EXITCODE,ANSISTRINGS,WIDESTRINGS
  22.   TEXTIO,CONSOLEIO,FILEIO,RANDOM,VARIANTS,OBJECTS,DYNARRAYS,THREADING
  23.   COMMANDARGS,PROCESSES,STACKCHECK,DYNLIBS,SOFTFPU,OBJECTIVEC1,RESOURCES
  24.   UNICODESTRINGS
  25.  
procedure mulu64(a, b: QWORD; out clo, chi: QWORD); assembler;
asm
  mov rax, a
  mov rdx, b
  mul rdx
  mov [clo], rax
  mov [chi], rdx
end;

ccrause

  • Full Member
  • ***
  • Posts: 222
Re: light pascal
« Reply #53 on: January 19, 2020, 03:07:31 pm »
Strange output. I have disabled  CLASSES, EXCEPTIONS - 
Code: Text  [Select]
  1. Recognized compiler and RTL features:
  2.   HEAP,INITFINAL,RTTI,CLASSES,EXCEPTIONS,EXITCODE,ANSISTRINGS,WIDESTRINGS
  3.   TEXTIO,CONSOLEIO,FILEIO,RANDOM,VARIANTS,OBJECTS,DYNARRAYS,THREADING
  4.   COMMANDARGS,PROCESSES,STACKCHECK,DYNLIBS,SOFTFPU,OBJECTIVEC1,RESOURCES
  5.   UNICODESTRINGS
  6.  
That is the list of features the compiler knows of.  It does not mean that the system unit was compiled with those features enabled.

julkas

  • Hero Member
  • *****
  • Posts: 520
  • KISS principle / Lazarus 2.0.6 / FPC 3.0.4
Re: light pascal
« Reply #54 on: January 19, 2020, 03:16:14 pm »
Strange output. I have disabled  CLASSES, EXCEPTIONS - 
Code: Text  [Select]
  1. Recognized compiler and RTL features:
  2.   HEAP,INITFINAL,RTTI,CLASSES,EXCEPTIONS,EXITCODE,ANSISTRINGS,WIDESTRINGS
  3.   TEXTIO,CONSOLEIO,FILEIO,RANDOM,VARIANTS,OBJECTS,DYNARRAYS,THREADING
  4.   COMMANDARGS,PROCESSES,STACKCHECK,DYNLIBS,SOFTFPU,OBJECTIVEC1,RESOURCES
  5.   UNICODESTRINGS
  6.  
That is the list of features the compiler knows of.  It does not mean that the system unit was compiled with those features enabled.
OK. How read / output enabled compiler features ? Simple question. I need only enabled compiler features.

ppcrossavr.exe -ir current output -
Code: Text  [Select]
  1. HEAP
  2. INITFINAL
  3. RTTI
  4. CLASSES
  5. EXCEPTIONS
  6. EXITCODE
  7. ANSISTRINGS
  8. WIDESTRINGS
  9. TEXTIO
  10. CONSOLEIO
  11. FILEIO
  12. RANDOM
  13. VARIANTS
  14. OBJECTS
  15. DYNARRAYS
  16. THREADING
  17. COMMANDARGS
  18. PROCESSES
  19. STACKCHECK
  20. DYNLIBS
  21. SOFTFPU
  22. OBJECTIVEC1
  23. RESOURCES
  24. UNICODESTRINGS
  25.  




« Last Edit: January 19, 2020, 03:29:23 pm by julkas »
procedure mulu64(a, b: QWORD; out clo, chi: QWORD); assembler;
asm
  mov rax, a
  mov rdx, b
  mul rdx
  mov [clo], rax
  mov [chi], rdx
end;

ccrause

  • Full Member
  • ***
  • Posts: 222
Re: light pascal
« Reply #55 on: January 19, 2020, 04:15:39 pm »
Whether a feature is available or not is not known by the compiler, since the feature support is included (or not) depending on the features enabled when the RTL was compiled.  The RTL supported features are available as compile time macros.  To see this add command line option -va when compiling a unit or program.  The compiler will then list the available features for the current subarch RTL.  Below I have copied the feature macros displayed after the compiler loaded the system unit when compiling one of my AVR projects:

Code: Text  [Select]
  1. Debug: [0.051] (SYSTEM)   (10056) Finished loading unit SYSTEM
  2. Debug: [0.051] Searching file adctest.pp... found
  3. Debug: [0.051] Searching file adctest.pp... found
  4. Debug: [0.051] /home/christo/fpc/fpc-avr/src/examples/adc4809/adctest.pp(3,5)  (3101) Macro defined: FPC_HAS_FEATURE_HEAP
  5. Debug: [0.051] /home/christo/fpc/fpc-avr/src/examples/adc4809/adctest.pp(3,5)  (3101) Macro defined: FPC_HAS_FEATURE_RTTI
  6. Debug: [0.051] /home/christo/fpc/fpc-avr/src/examples/adc4809/adctest.pp(3,5)  (3101) Macro defined: FPC_HAS_FEATURE_TEXTIO
  7. Debug: [0.051] /home/christo/fpc/fpc-avr/src/examples/adc4809/adctest.pp(3,5)  (3101) Macro defined: FPC_HAS_FEATURE_FILEIO
  8. Debug: [0.051] /home/christo/fpc/fpc-avr/src/examples/adc4809/adctest.pp(3,5)  (3101) Macro defined: FPC_HAS_FEATURE_OBJECTS
  9. Debug: [0.051] (ADCTEST)  (10057) Registering new unit OBJPAS

This way you can test whether a feature is supported before trying to use it in code:
Code: Pascal  [Select]
  1. type
  2.   {$if defined(FPC_HAS_FEATURE_CLASSES)}
  3.   TTest = class
  4.     procedure foo;
  5.   end;
  6.   {$elseif defined(FPC_HAS_FEATURE_OBJECTS)}
  7.   TTest = object
  8.     procedure foo;
  9.   end;
  10.   {$else}
  11.     {$fatal 'Either CLASSES or OBJECTS must be supported for this to compile'}
  12.   {$endif}

julkas

  • Hero Member
  • *****
  • Posts: 520
  • KISS principle / Lazarus 2.0.6 / FPC 3.0.4
Re: light pascal
« Reply #56 on: January 19, 2020, 05:47:47 pm »
Thanks. -va option is very useful.
procedure mulu64(a, b: QWORD; out clo, chi: QWORD); assembler;
asm
  mov rax, a
  mov rdx, b
  mul rdx
  mov [clo], rax
  mov [chi], rdx
end;