RAM size problems

Coding and general discussion relating to the compiler

Moderators: David Barker, Jerry Messina

Post Reply
maisoft
Posts: 8
Joined: Mon Apr 17, 2017 6:16 pm

RAM size problems

Post by maisoft » Sun Sep 03, 2017 6:58 pm

I wrote a small program and the RAM memory was unexpected full, so I tried the causes. :?:
I did some simple tests, insert or remove instances and check the size of the compiled program.
This helps me understand how the functions I want to use lie in the memory space of the CPU. The processor I use

has little/normal memory eeprom / ram.
I can not understand how the compiler handles some instances of strings.
This is a test that anyone can do

// Cpu PIB18LF14K22 (Ran 512 Bytes)

// Test String
Public Dim MyStr As String

case 1) I do not use MyStr, compiling -> success: 1613 Program Bytes Used, 300 Variable Bytes Used, OK!

case 2) Add instruction in the my program:
MyStr = "abcd",
compiling -> success: 1637 PBU / 324 VBU -> Increase of 24PBU / 24VBU Bytes, that's right?

case 3) then reduce the string content to a single character
MyStr = "a",
compiling -> success: 1635 PBU / 350 VBU -> Increase of 22 PBU / 50 VBU Bytes, why it goes to 50 Bytes instead of staying at 24 Bytes? :?: :?:

// Test USART

Public Dim MyStr As String

case 1) I do not use MyStr,
compiling -> success: 1613 Program Bytes Used, 300 Variable Bytes Used, OK!

case 2) Add instruction in the my program:
MyStr = FloatToStr(sin(10))
usart.write((MyStr), 13, 10)
compiling -> success: 4757 PBU / 397 VBU -> Increase of 3144 PBU / 97 50 VBU Bytes, the "FloatToString" + "sin" functions cost me so much (maybe just the first time I use these?)

case 3) instead of the two instructions I put one, the following
Write(FloatToStr(sin(10)), 13, 10)
Surprise:
compiling -> success: 4795 PBU / 510 VBU -> higher increase of 3182 PBU / 210 VBU, but why?

With these prerogatives how I can use my CPU with 512 Bytes, two instructions like this and the program will override the RAM.

Maybe I'm stupid but please help me to understand,
thank you in advance
Umberto

Jerry Messina
Swordfish Developer
Posts: 1469
Joined: Fri Jan 30, 2009 6:27 pm
Location: US

Re: RAM size problems

Post by Jerry Messina » Sun Sep 03, 2017 8:20 pm

There are 25 bytes of system variables reserved by the compiler. If you compile an empty program you'll see '25 variables bytes used'.

By default, strings are 24 bytes long... 23 chars + 0 null char = 24 bytes
So, for a single string...

Code: Select all

device = 18LF14K22

dim MyStr as string

mystr = "12345678901234567890123"   // 23 chars + null = 24 (49 total used)
// for some reason using a single char causes another string-sized memory allocation (75 total used)
'mystr = "1"
// but using anything other than a single char is fine...
mystr = "12"    // 49 total used
As you can see from the comments above there's something odd that happens if you use a single-char string that doesn't happen otherwise. If you uncomment the line you'll see. That should explain your first example.

As far as the second example, floating-point operations and conversions are VERY code and ram hungry.

String operations can get very memory hungry too, as the compiler will create all sorts of "extra" copies of strings as you pass them back and forth between functions so that your original strings are not modified. Sometimes even simple operations like 'string1 = string2 + string3' can consume more memory than you think.

maisoft
Posts: 8
Joined: Mon Apr 17, 2017 6:16 pm

Re: RAM size problems

Post by maisoft » Mon Sep 04, 2017 8:33 pm

Thank you very much for the quick response.
I make a premise: I started using Swordfish for six months, I'm not expert, I still have to learn a lot about using Swordfish.
The programs I must develop contain few mathematical and trigonometric operations, in floating point.
It's been three months that I work in this project but I can not overcome some obstacles, while compiling I encounter a lot of "warning" and "error", which I'm correcting, but it's a hellish job :cry: .
So in this case, I have few chances to get a compiled program in my device. It contains only 512 bytes RAM, there are few for this hungry "swordfish".

User avatar
David Barker
Swordfish Developer
Posts: 1214
Joined: Tue Oct 03, 2006 7:01 pm
Location: Saltburn by the Sea, UK
Contact:

Re: RAM size problems

Post by David Barker » Tue Sep 05, 2017 7:01 am

Have you run out of RAM yet?

The compiler uses what it has to use in order to do it's job. However, please note that Swordfish uses a compile time stack. This means that RAM is recycled when a variable or temporary variable goes out of scope. There is some information here:

http://www.sfcompiler.co.uk/swordfish/o ... eRecycling

In short, RAM variables used in subs and function are recycled. Only global, module level RAM variables are not. When you start coding, RAM usage tends to inflate but will settle down as your program grows.

maisoft
Posts: 8
Joined: Mon Apr 17, 2017 6:16 pm

Re: RAM size problems

Post by maisoft » Tue Sep 05, 2017 8:15 pm

Thanks for the link " ... FrameRecycling"
So, if I understand, inserting instructions with many variables within sub routines or functions, ram request is optimized, ie the ram request does not increase in proportion to the number of hungry instructions. This modality of structure could solve my problem.
Unfortunately I have a number of "include" and common variables that occupy a lot of ram, as shown below:

Device = 18F14k22
Clock = 20

Include "I2Cmu.bas" // I2C correct
Include "USART.bas" // (41B)Hardware USART library (seriale interna)
Include "SUART.bas" // (12B)Software p library (seriale esterna)
Include "ISRRX.bas" // (75B)Interrupt based USART receive library
Include "Shift.bas" // (0B)Shift library
Include "Convert.bas" // (7B)Number conversion library
Include "Math.bas" // (0B)Floating point math library
Include "EEPROM.bas" // (6B)

+ 18 Variables As Float + 2 String = 223 total variable bytes used

If I add the following statement the risk of going beyond ram range:
Write(FloatToStr(sin(MyData),3,6), 13, 10) // > 250 byte

and so I have only a few free bytes RAM (about 40)

SHughes_Fusion
Posts: 219
Joined: Wed Sep 11, 2013 1:27 pm
Location: Chesterfield

Re: RAM size problems

Post by SHughes_Fusion » Mon Oct 02, 2017 9:20 am

Swordfish is set up in general to make it easy for the programmer but not necessarily be the most optimised.

If possible, define strings to the maximum size they need to be, rather than allowing SF to create a default size string.

I've found that you can save a load of both code and data memory by creating your own FloatToStr routines, especially if you only need a few places of accuracy - by default it creates a 26 character long string. You can also save space by passing strings ByRef - this passes a pointer to the string rather than passing the string itself.

There is lots of scope to optimise both RAM and ROM usage, the only downside is the code becomes a bit less readable and easier to break...

Post Reply