SmartMath Plugin - Real-time Calculations in AkelPad

[DV]

to reduce dll size

Cool! Updated the Compile32.bat and Compile64.bat. Now they produce smaller binaries to AkelFiles\Plugs and AkelFiles\Plugs64.

[ewild]

Code: Select all

fbc -dll -gen gcc -arch x86_64 -x "SmartMath.dll" -strip -O 2 -Wc -Os "SmartMath.bas" "SmartMath_Config.bas" "SmartMath_Format.bas" "SmartMath_CopyNormalize.bas" "SmartMath_About.bas" "SmartMath_Menu.bas" "MathParser.bas"

to reduce dll size.

There is a minor conflict in the command:
-O 2 asks for high performance.
-Wc -Os asks for the smallest size.
To resolve the conflict, you should choose one based on your priority.
When to provide both, the compiler doesn't "mix" them; the last one processed (in this case, the one passed via -Wc) generally wins.

Fixing the conflict:

1. Option 1: Prioritize Performance (Speed)
   If the DLL performs heavy calculations or logic where speed is critical, use -O 2 or -O 3 and remove the size optimization.
   It tells GCC to prioritize execution speed, even if it makes the file slightly larger by unrolling loops or inlining functions.
   Result: Faster execution, slightly larger file.
   The revised command (Standard Balance):
   fbc -dll -gen gcc -arch x86_64 -x "my.dll" -strip -O 2 "my.bas"
   The revised command (Max Speed):
   fbc -dll -gen gcc -arch x86_64 -x "my.dll" -strip -O 3 "my.bas"
2. Option 2: Prioritize Smallest File Size
   If the DLL is simple or needs to be as lightweight as possible (e.g., for web distribution or embedded use), keep -Os and remove the general optimization flag.
   It enables all -O2 optimizations that don't increase code size, then adds specific passes to shrink the binary further.
   Result: Smallest possible .dll file, moderate execution speed.
   The revised command:
   fbc -dll -gen gcc -arch x86_64 -x "my.dll" -strip -Wc -Os "my.bas"

[ewild]

I've made some tests regarding the information in my previous message, and here are the results:

Code: Select all

SmartMath.dll size       :: optimization  :: priority, notes
175.50 kB (179712 bytes) :: -O 2 -Wc -Os  :: Size; Smallest Size, '-O 2' vs '-Wc -Os' conflict
175.50 kB (179712 bytes) :: -Wc -Os       :: Size; Smallest Size, no conflicts
194.00 kB (198656 bytes) :: -O 2 -Wc -O2  :: Standard Professional Build, Ultra-Stable.
                                             Choose only if you encounter a strange bug or a crash with Level 3
                                             and need to move to a more "conservative" setup.
194.00 kB (198656 bytes) :: -O 3 -Wc -O2  :: Performance; Sweet Spot (Best Balance);
                                             The fastest possible DLL that is still considered "safe."
                                             Most modern FreeBASIC developers prefer this for 64-bit builds.
232.50 kB (238080 bytes) :: -O 3 -Wc -O3  :: Performance; Absolute Speed, can be buggy
271.00 kB (277504 bytes) :: none          :: * the previously used compiling command

It's up to a developer to choose the optimization method, depending on the speed or size priority one prefers.
However, if it is the DLL size alone, it is clear that there's no need to use the conflicting '-strip -O 2 -Wc -Os' - the '-strip -Wc -Os' in this case is enough.

[Diamen]

Note that fbc -O 2 -Wc -O2 is redundant.

You're requesting O2 both via the fbc frontend and directly via -Wc to GCC. While this isn't a conflict (unlike your previous -Os issue), it’s unnecessary—fbc handles the backend flag for you. You can simplify it to just -O 2.

[ewild]

Note that fbc -O 2 -Wc -O2 is redundant...

No, it is not redundant.

While it looks like you are repeating "-O 2", you are actually talking to two different programs that perform two different stages of the build.

Why do you need both:
The compilation process with -gen gcc works like a relay race:

1. Stage 1: FreeBASIC (-O 2)
   Translates your .bas code into .c (C source code).
   The Benefit: -O 2 tells FB to write "smart" C code.
   It optimizes how it handles BASIC-specific things like array lookups, string memory, and variable scopes.
2. Stage 2: GCC (-Wc -O2)
   Translates that .c code into a .dll (Machine code).
   The Benefit: -Wc -O2 tells GCC to use its own advanced logic to optimize the machine code.
   It handles CPU-level things like instruction scheduling, register allocation, and branch prediction.

What happens if you remove one?

• If you remove -O 2:
  FreeBASIC will generate "lazy" C code.
  Even if GCC is set to -O2, it has to work much harder to fix the unoptimized C code, and the final result will likely be slower.
• If you remove -Wc -O2:
  FreeBASIC will write great C code, but GCC will compile it with no optimization (Level 0).
  This results in a "heavy," slow DLL because the final machine code hasn't been streamlined for the CPU.

[Diamen]

No, it is not redundant.

ty.

do it is possible to add simple date operation?
12/05/2025 + 15
2025/05/12 + 1
12:30+6:23

[ewild]

DV
With the latest updates, I can no longer build a working SmartMath.dll from your sources.
Upon its call, SmartMath.dll immediately crashes AkelPad.

Environment:

Microsoft Windows 11 Pro 25H2 build 26200 revision 8328

AkelPad 4.10.0 x64 (latest)
https://akelpad.sourceforge.net/files/AkelPad-x64.zip

Smart-Math
https://github.com/d0vgan/AkelPad-Smart ... ulator.zip

FreeBASIC
https://downloads.sourceforge.net/fbc/F ... -11.2.0.7z

GCC and MinGW-w64 for Windows
https://github.com/brechtsanders/winlib ... .0.0-r1.7z

[Diamen]

DV
With the latest updates, I can no longer build a working SmartMath.dll from your sources.
Upon its call, SmartMath.dll immediately crashes AkelPad.

Work fine here for me.
FreeBASIC-1.10.1-win64.7z

[ewild]

Work fine here for me.

Your DLL crashed the AkelPad the same way as mine.
So, I started removing any previous SmartMath settings, and when I deleted its Registry entry, your DLL began working, and so did mine, too.
Thanks.

FreeBASIC-1.10.1-win64.7z

How are you using it?
I was using it too, but switched to another version, since FreeBASIC-1.10.1-win64.7z does not include "inc\win\rc", which is in the DV's Compile64.bat command:

Code: Select all

windres -F pe-x86-64 -c 65001 -I "%FB_HOME%\inc\win\rc" -i SmartMath.rc -o "%OUT_DIR%\SmartMath_res.o"

There's no such directory within FreeBASIC-1.10.1-win64.7z, this path ends at "inc\win" there.

[Diamen]

I used previous:

Code: Select all

fbc -dll -gen gcc -arch x86_64 -x "SmartMath.dll" -strip -O 2 -Wc -O2 "SmartMath.bas" "SmartMath_Config.bas" "SmartMath_Format.bas" "SmartMath_CopyNormalize.bas" "SmartMath_About.bas" "SmartMath_Menu.bas" "MathParser.bas"

[ewild]

So, I started removing any previous SmartMath settings, and when I deleted its Registry entry, your DLL began working, and so did mine, too.

It turns out, this is because SmartMath requires all its entries in the Registry to be strings (REG_SZ: Standard Null-terminated Unicode string).
Whenever, for whatever reason, any SmartMath's entry in the Registry becomes binary (REG_BINARY: Raw binary data), SmartMath/AkelPad would crash, e.g.:

Code: Select all

parameter :: visible value          :: type                               :: result 
Color     :: dword:00008000 (32768) :: REG_BINARY: Raw binary data [hex:] :: SmartMath/AkelPad crash
Color     :: 32768                  :: REG_SZ: Standard string [hex(1)]   :: OK

[ewild]

I used previous...

So, you are just ignoring the newly made DLL metadata part.
OK, I get it, thanks.

[DV]

I've updated Compile.bat, Compile32.bat and Compile64.bat to require the correct path to FreeBasic to be specified inside of these files.

[Diamen]

Compile64.bat refer to "%FB_HOME%\bin\win32" but for me work "%FB_HOME%\bin\win64".
Do is it an Mistake?

[DV]

Compile64.bat refer to "%FB_HOME%\bin\win32" but for me work "%FB_HOME%\bin\win64".

I think you are right. Corrected.

Also, looking at the updated logic of the source code, I feel like the function `UpdateMarginAndState` in "SmartMath.bas" is either no more needed or can be significantly simlified.
I've already exceeded my monthly usage of the Cursor IDE, plus I can't really rely on it in questions related to GUI which it can not test.
So, it would be great if c-sanchez inspects the updated "SmartMath.bas" carefully.

Even though I have better understanding of FreeBasic's syntax now and even made several changes around `lpEditProcData`, `lpMainProcData` and `lpFrameProcData`, I can't really say I understand the entire logic of "SmartMath.bas".