Large_array update

104 views
Skip to first unread message

Oliver Seitz

unread,
Dec 9, 2020, 9:29:59 AM12/9/20
to Jallib
Hi all!

Recently, new PIC controllers were released which break through the 4kB RAM boundary, and there are more announced with up to 13kB.

The compiler has been updated to correctly address all of that memory, thanks Rob!

Now, if you want to use that lot of memory, soon you'll notice that there is no way to use it in a linear way. Arrays can only hold 256 bytes, and the large_array libs only go to 2048 bytes. There are four of them, so even when you use the RAM in four chunks, with the current version of large_array you can only use 8kB.

Attached you'll find a bash script which generates the large_array libs, including the output files adjusted to cover the so-far largest RAM space in a single array.

The source code generated is nearly the same as with the current large_array (including typos in the comments) written by Matt.

Of course everyone is encouraged to test your programs with these libraries, but as the source code generated is virtually the same as the current, I presume there shouldn't be any problems.

Greets,
Kiste
large_array.tgz

Rob CJ

unread,
Dec 9, 2020, 12:50:30 PM12/9/20
to Jallib
Hi Kiste,

Very nice. I ran your script and it seems to work perfectly. I did not yet test all memory locations.

We could add enough large arrays to Jallib to cover the 13 kB and we should mention that they are created with your script. So we would at least need 7 large arrays instead of the current 4.

If more memory comes available we could generate more libraries. We must also save your script on GitHub then.

What do the others think?

Kind regards,

Rob



Van: 'Oliver Seitz' via jallib <jal...@googlegroups.com>
Verzonden: woensdag 9 december 2020 15:29
Aan: Jallib <jal...@googlegroups.com>
Onderwerp: [jallib] Large_array update
 
--
You received this message because you are subscribed to the Google Groups "jallib" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jallib+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jallib/1896695521.6146523.1607524193216%40mail.yahoo.com.

Oliver Seitz

unread,
Dec 9, 2020, 1:14:13 PM12/9/20
to jal...@googlegroups.com
Hi Rob,

seems like you didn't see that the maximum size of the large arrays is also configurable. I've set it to 14.5kB:

max_bytes_pic16=$((58*256))

That way you can use all the memory in a linear fashion without stitching together several large_arrays. 

I would, however, keep a minimum of four large_arrays as it was like that until now. 

The only drawback on the greater size of the large_array is that the compiler takes longer to compile. Over 1700 arrays of 256 bytes each are defined, most of them thrown out again as unused. That takes a bit of time.

Greets,

Kiste

Am Mittwoch, 9. Dezember 2020, 18:50:32 MEZ hat Rob CJ <rob...@hotmail.com> Folgendes geschrieben:


Matt Schinkel

unread,
Dec 10, 2020, 1:03:44 AM12/10/20
to jal...@googlegroups.com
Great work Kiste, time to fix those typos. You can add your name to the library somewhere.

When I originally created this I didn't think anyone would use it, it was just a fun lib to create at the time. I guess my bit array library is more useless.

Matt.

Sent from my Android device.

From: 'Oliver Seitz' via jallib <jal...@googlegroups.com>
Sent: Wednesday, December 9, 2020 1:12:04 PM
To: jal...@googlegroups.com <jal...@googlegroups.com>
Subject: Re: [jallib] Large_array update
 

Oliver Seitz

unread,
Dec 10, 2020, 12:03:03 PM12/10/20
to jal...@googlegroups.com
Hi!

I've added some "if"s, reduced compile time by 15% and found a bug ;-)

It was even present in the current lib:
    ...
    260    elsif LARGE_ARRAY_1_SIZE > 512 then
    261       if address >= 512 then
    262          _large_array_1_byte_3c[address - 512] = data
    263       elsif address >= 256 then
    264          _large_array_1_byte_2c[address - 256] = data
    265       else
    266          _large_array_1_byte_1c[address - 0] = data
    267       end if
    268    elsif LARGE_ARRAY_1_SIZE > 256 then
    ...

If the chosen size is a multiple of the chunk size, the highest variable won't work. If LARGE_ARRAY_1_SIZE is 512, it is not *greater* than 512, therefore  only the "greater-than-256" part will be compiled.

By the way, the part like "-256", "-512"... is useless, it can be replaced by byte(address)... Think I have a look if it's worth the change ;-)

Greets,
Kiste
Am Donnerstag, 10. Dezember 2020, 07:03:45 MEZ hat Matt Schinkel <mattsc...@hotmail.com> Folgendes geschrieben:


Oliver Seitz

unread,
Dec 10, 2020, 2:50:45 PM12/10/20
to 'Oliver Seitz' via jallib
Sorry, if there is a bug, it's somewhere else and doesn't do any harm in the current libs, I was a bit confused. ;-)

Greets,
Kiste

Am Donnerstag, 10. Dezember 2020, 18:35:04 MEZ hat 'Oliver Seitz' via jallib <jal...@googlegroups.com> Folgendes geschrieben:


Rob Hamerling

unread,
Dec 13, 2020, 10:23:08 AM12/13/20
to jal...@googlegroups.com

Hello Kiste


On 09/12/2020 15.29, 'Oliver Seitz' via jallib wrote:

Attached you'll find a bash script which generates the large_array libs, including the output files adjusted to cover the so-far largest RAM space in a single array.

Nice feature!
Since bash is not particularly cross-platform, it would be nice to translate it to Python. I believe there exist 'bash-to-python' scripts which might do the job.

Regards, Rob.


--
Rob Hamerling, Vianen, NL

Oliver Seitz

unread,
Dec 13, 2020, 11:11:00 AM12/13/20
to jal...@googlegroups.com
Hi Rob,

I've been optimizing the generated code the last few days, there's not much of Matt's left... But the compiled size is in most cases significantly smaller (like 1100 words less) and in some cases quite a bit faster (running a test program in 66% of the time).

Now I was thinking about the lot of comments and nearly-static parts of the code, which is now duplicated in my script. Bash is not very good in outputting nearly-identical text to several files, so your suggestion to use another language is very much appreciated! :-)

If anyone's interested, this is how the "address decoding" works now:

-- get a value from a large byte array
function large_array_1'get(word in address) return byte is
   var byte data
   
   if LARGE_ARRAY_1_SIZE > 1792 then
      if address >= 1792 then
         data = _large_array_1_byte_8h[address - 1792]
      elsif address >= 1536 then
         data = _large_array_1_byte_7h[address - 1536]
      elsif address >=...

This is what it looks like now:

-- get a value from a large byte array
function large_array_1'get(word in address) return byte is
   var byte data
   var byte address_lo at address+0
   var byte address_hi at address+1
   
   if LARGE_ARRAY_1_SIZE > 1792 then
      case address_hi of
         07 : data = _large_array_1_byte_08_08[address_lo]
         06 : data = _large_array_1_byte_07_08[address_lo]
         05 : data = _large_array_1_byte_06_08[address_lo]
        ...

This example is from the byte/PIC16 library, which is the easiest to do. Especially the PIC14 libraries with 80-byte arrays are not that easy to decode, but using a case statement instead of a chain of elsif's justifies the address calculations.

Greets,
Kiste

Am Sonntag, 13. Dezember 2020, 16:23:09 MEZ hat Rob Hamerling <robham...@gmail.com> Folgendes geschrieben:


--
You received this message because you are subscribed to the Google Groups "jallib" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jallib+un...@googlegroups.com.
To view this discussion on the web visit

Rob CJ

unread,
Dec 13, 2020, 12:05:01 PM12/13/20
to jal...@googlegroups.com
Hi Kiste,

It would be nice to have larger arrays than only 2k. Maybe we should add large_array_4k.jal, large_array_8k.jal, large array_16k.jal. You can generated those with your script, right? 

As suggested by Rob Hamerling, it would be nice to have a Python version so you can run it both on a Windows machine and a Linux machine.

Kind regards,

Rob

Van: 'Oliver Seitz' via jallib <jal...@googlegroups.com>
Verzonden: zondag 13 december 2020 17:10
Aan: jal...@googlegroups.com <jal...@googlegroups.com>
Onderwerp: Re: [jallib] Large_array update
 

Oliver Seitz

unread,
Dec 13, 2020, 12:55:53 PM12/13/20
to jal...@googlegroups.com
Hi Rob,

the current lib is already "self-adjusting", you can request any size of array between 1 and 2048 bytes. By the help of an optimizing compiler, only the requested amout of RAM is assigned.

My new lib can assign any size between 1 and (configurable, my default would be 14848) bytes, so there's no need to have seperate libs for different size ranges.

I've never really used python, but this is a good excuse now to get started. I could do it in pascal, no? It runs on almost any platform ;-)

Greets,
Kiste

Am Sonntag, 13. Dezember 2020, 18:05:03 MEZ hat Rob CJ <rob...@hotmail.com> Folgendes geschrieben:


Rob CJ

unread,
Dec 14, 2020, 4:07:35 AM12/14/20
to jal...@googlegroups.com
Hi Kiste (and others),

Can you send your latest version of your script? 

I propose to add a library called large_array_13k.jal or should we give it another name like super_array.jal? I think the size must be in the filename in case MicroChip releases a chip with 32k.

@Others: Suggestions for a library name are welcome.

Python seems to be the most popular language to use. I could give it a try to translate your script but currently I am investigating a compiler issue that takes up my time.

Thanks.

Kind regards,

Rob



Van: 'Oliver Seitz' via jallib <jal...@googlegroups.com>
Verzonden: zondag 13 december 2020 18:55

Oliver Seitz

unread,
Dec 14, 2020, 8:48:21 AM12/14/20
to jal...@googlegroups.com
Hi all!

I would prefer not to change names, just replace the already existing libraries. I'm sure it is compatible. The code generated is in all cases smaller using the new lib, and executes faster in most cases. Only for 16bit on a PIC14 core I've seen the program running slower by about 2%, in all other cases it was faster by up to 33%. Speeding up the 16bit/PIC14 case would cost around 20 code words. Would still be over 200 code words smaller than the current lib, though.

What I did not yet investigate: While usually needing the same or up to 7 bytes less, the new lib uses more RAM in two variants, 1 additional byte at 16bit/PIC14 and 4 additional bytes at 32bit/PIC16. That might be an issue, if an existing program is designed to use almost all RAM. 

The current address range of the PIC16 cores can only address 16kbyte. If there's a chip with more than 14kbyte GPR, the compiler has to be extended. If that happens, rebuilding the libs with the then-maximum amount of GPR would be the least problem. So it wouldn't be difficult to maintain compatibility within each package: As long as the compiler doesn't support more than 14k, the library doesn't need to. And if one is changed, the other is done easily.

What gets onto my mind thinking about names: The current lib is designed to make use of up to four large arrays. The library is split up into 28 source files. When I'm already rewriting the lib, shouldn't I combine it into one, or at most four, source files?

The script produces working libraries, but the comments arten't as nice as I wanted them ;-)

Greets,
Kiste

Am Montag, 14. Dezember 2020, 10:07:35 MEZ hat Rob CJ <rob...@hotmail.com> Folgendes geschrieben:


alternate_large_array.sh

Matt Schinkel

unread,
Dec 14, 2020, 12:43:28 PM12/14/20
to jal...@googlegroups.com
Hi, you may replace my libraries if you wish.

Since the code is generated, I'd prefer one library. Several samples will need to be updated.

Matt.

From: 'Oliver Seitz' via jallib <jal...@googlegroups.com>
Sent: December 14, 2020 8:44 AM

To: jal...@googlegroups.com <jal...@googlegroups.com>
Subject: Re: [jallib] Large_array update
--
You received this message because you are subscribed to the Google Groups "jallib" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jallib+un...@googlegroups.com.

Rob CJ

unread,
Dec 15, 2020, 3:42:01 AM12/15/20
to jal...@googlegroups.com
Hi Matt, Kiste,

Why not just add a new large array without a number and keep the old ones? All other large arrays carry a number.

So just large_array.jal

Reason is that we are not sure if other JAL users have uses large_array_x.jal (x = 1..4) in one of there programs and we remain backwards compatible if we keep them.

I know I used large_array_1.jal in one of my esp8266 sample programs. I have no problems with fixing sample files, I am only concerned about backwards compatibility.

Kind regards,

Rob

Van: jal...@googlegroups.com <jal...@googlegroups.com> namens Matt Schinkel <mattsc...@hotmail.com>
Verzonden: maandag 14 december 2020 18:43

Aan: jal...@googlegroups.com <jal...@googlegroups.com>
Onderwerp: Re: [jallib] Large_array update

Oliver Seitz

unread,
Dec 15, 2020, 3:55:51 AM12/15/20
to jal...@googlegroups.com
Hi Rob,

good point. How about this:

large_array.jal
large_array_1.jal
...
large_array_4.jal

where large_array.jal does all the work, while the numbered libs only (issue a deprecated warning and) include the general lib.

Greets,
Kiste

Am Dienstag, 15. Dezember 2020, 09:42:03 MEZ hat Rob CJ <rob...@hotmail.com> Folgendes geschrieben:


Rob CJ

unread,
Dec 15, 2020, 3:59:03 AM12/15/20
to jal...@googlegroups.com
Hi Kiste,

Yes, that would be a good solution.

Met vriendelijke groet,
Rob Jansen
From: 'Oliver Seitz' via jallib <jal...@googlegroups.com>
Sent: Tuesday, December 15, 2020 9:55:45 AM

Rob CJ

unread,
Dec 15, 2020, 5:57:06 AM12/15/20
to jal...@googlegroups.com
Hi Kiste,

I ran your script to see the results I now I understand why Matt suggested to replace the libraries. I agree with that but I would keep the four libraries. It can be that you need two independent large arrays of different sizes and then it would be handy if you could select from more large array libraries.

Some suggestions to change:
1) Make the last copyright year 2020 (or 2021 if you are done next year).
2) Add your name to the revision of all created files (since you changed them all)
3) Change the compiler version to v25r4.

I can run the script for you and upload all versions to GitHub if you want. For the time being we should also upload your script to GitHub.

Kind regards,

Rob



Van: jal...@googlegroups.com <jal...@googlegroups.com> namens Rob CJ <rob...@hotmail.com>
Verzonden: dinsdag 15 december 2020 09:59

Oliver Seitz

unread,
Dec 15, 2020, 7:47:19 AM12/15/20
to jal...@googlegroups.com
Hi Rob,

everything you mention is true - and in my mind everything was solved already :-)

The plan is this:

You order what you need by defining
const LARGE_ARRAY_SIZE = 600 
const LARGE_ARRAY_VARIABLE_SIZE = 2

or 

const LARGE_ARRAY_1_SIZE = 300 
const LARGE_ARRAY_1_VARIABLE_SIZE = 4

const LARGE_ARRAY_2_SIZE = 600 
const LARGE_ARRAY_2_VARIABLE_SIZE = 1

...

Then, you only include the one library, which, depending on the defined constants, gives you up to four arrays as specified.

The library itself would then check if it was already included, so that a program would compile, even if the lib is included more than once.

That way, the new lib is fully compatible with the existing solution, the only change that should be made in an existing program is to replace

include large_array_1
include large_array_2
include large_array_3
include large_array_4

by

include large_array

but even that change is not compulsory, I would like to issue a warning, though. 

Suggestions 1),2) and 3) is what I meant with "the comments aren't nice". Those comments are duplicated in several places in the current script. I did not bother to change them, as the python version will get a different structure where there's only one place to change. 

I think I will need several days to complete the python script, after that I would highly appreciate if you would upload it all :-)

Greets,
Kiste


Am Dienstag, 15. Dezember 2020, 11:57:07 MEZ hat Rob CJ <rob...@hotmail.com> Folgendes geschrieben:


Oliver Seitz

unread,
Dec 19, 2020, 1:52:06 PM12/19/20
to 'Oliver Seitz' via jallib
Hi all!

Python was a very good recommendation, thank you Rob Hammerling :-)

I dropped the idea of the array with no index, that would have been a difficult and nearly useless addition.

Other bad news: The PIC14/byte*2 version needs one byte GPR more than the old lib, PIC16/byte*4 even four bytes more.

But that is it, all other versions need the same or less GPR. Execution time and code size are now even 12-25% smaller than with my last version, now my test program in the best cases needs little more than half the time compared to the original lib, code is between 300 and 1000 words smaller. 

I did some tests, but only with one array at a time. 

Greets,
Kiste


generate_large_array.py

Rob CJ

unread,
Dec 20, 2020, 3:01:46 AM12/20/20
to jal...@googlegroups.com
Hi Olivers,

Great work! Wow, it generates a JAL source file of almost 100.000 lines of code but compiles fast.

Can you have a look at sample 16f1825_large_array.jal? It does not yet compile with this library and I can't see why. This is - I think - the only sample file that uses 4 large arrays. The error message is as follows:

d:\PIC\Projects\2020\New_Large_Array\16f1825_large_array.jal:81: "large_array_2" not defined
d:\PIC\Projects\2020\New_Large_Array\16f1825_large_array.jal:81: '=' expected (got 'const')
d:\PIC\Projects\2020\New_Large_Array\16f1825_large_array.jal:87: "large_array_3" not defined
d:\PIC\Projects\2020\New_Large_Array\16f1825_large_array.jal:87: '=' expected (got 'const')
d:\PIC\Projects\2020\New_Large_Array\16f1825_large_array.jal:93: "large_array_4" not defined
d:\PIC\Projects\2020\New_Large_Array\16f1825_large_array.jal:93: '=' expected (got 'var')
d:\PIC\Projects\2020\New_Large_Array\16f1825_large_array.jal:104: "word_array" not defined
d:\PIC\Projects\2020\New_Large_Array\16f1825_large_array.jal:104: 'end' expected (got 'word_array')
d:\PIC\Projects\2020\New_Large_Array\16f1825_large_array.jal:104: {FOR starts at d:\PIC\Projects\2020\New_Large_Array\16f1825_large_array.jal:103}
d:\PIC\Projects\2020\New_Large_Array\16f1825_large_array.jal:104: "word_array" not defined
d:\PIC\Projects\2020\New_Large_Array\16f1825_large_array.jal:104: 'end' expected (got 'word_array')
d:\PIC\Projects\2020\New_Large_Array\16f1825_large_array.jal:104: {FOREVER starts at d:\PIC\Projects\2020\New_Large_Array\16f1825_large_array.jal:98}
d:\PIC\Projects\2020\New_Large_Array\16f1825_large_array.jal:104: "word_array" not defined
d:\PIC\Projects\2020\New_Large_Array\16f1825_large_array.jal:104: unexpected token: word_array
14 errors, 0 warnings

Thanks

Kind regards,

Rob

Van: 'Oliver Seitz' via jallib <jal...@googlegroups.com>
Verzonden: zaterdag 19 december 2020 19:52
Aan: 'Oliver Seitz' via jallib <jal...@googlegroups.com>

Onderwerp: Re: [jallib] Large_array update
--
You received this message because you are subscribed to the Google Groups "jallib" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jallib+un...@googlegroups.com.

Oliver Seitz

unread,
Dec 20, 2020, 3:29:41 AM12/20/20
to jal...@googlegroups.com
Hi Rob,

thanks for having a look. It's a problem of the "include-more-than-once"-mechanism. I changed the sample like this, now it compiles:

-- Setup a large byte array.
const dword LARGE_ARRAY_1_SIZE = 120         -- choose number of array variables
const dword LARGE_ARRAY_1_VARIABLE_SIZE = 1  -- choose size of variables (byte*1)
--include large_array_1                        -- include the array library

-- Setup a large word array.
const dword LARGE_ARRAY_2_SIZE = 120         -- choose number of array variables
const dword LARGE_ARRAY_2_VARIABLE_SIZE = 2  -- choose size of variables (byte*1)
--include large_array_2                        -- include the array library

-- Setup a large dword array.
const dword LARGE_ARRAY_3_SIZE = 120         -- choose number of array variables
const dword LARGE_ARRAY_3_VARIABLE_SIZE = 4  -- choose size of variables (byte*1)
--include large_array_3                        -- include the array library

-- Setup another large byte array.
const dword LARGE_ARRAY_4_SIZE = 120         -- choose number of array variables
const dword LARGE_ARRAY_4_VARIABLE_SIZE = 1  -- choose size of variables (byte*1)
include large_array_4                        -- include the array library
alias byte_array is large_array_1            -- rename/alias the array to byte_array
alias word_array is large_array_2            -- rename/alias the array to word_array
alias dword_array is large_array_3           -- rename/alias the array to dword_array
alias another_byte_array is large_array_4    -- rename/alias the array to byte_array

That's not a solution, it's a part of the debugging process. I feel a bit unclear about how my "if defined("-statements work, think I'll have to take a close look at the compiler options to see what's going on ;-)

Greets,
Kiste

Am Sonntag, 20. Dezember 2020, 09:01:48 MEZ hat Rob CJ <rob...@hotmail.com> Folgendes geschrieben:


Oliver Seitz

unread,
Dec 20, 2020, 3:59:56 AM12/20/20
to 'Oliver Seitz' via jallib
Hi Rob,

Does the compiler deny to include the same lib multiple times? If so, I can't help :-(

It says:

including 'large_array_1.jal'
including '/home/kiste/Pic-LBC/jallib/include/jal/large_array_1.jal'
including 'large_array.jal'
including '/home/kiste/Pic-LBC/jallib/include/jal/large_array.jal'
including 'large_array_2.jal'
including '/home/kiste/Pic-LBC/jallib/include/jal/large_array_2.jal'
including 'large_array.jal'
including '/home/kiste/Pic-LBC/jallib/include/jal/large_array.jal'
blocking source: /home/kiste/Pic-LBC/jallib/include/jal/large_array.jal

Greets,
Kiste

Am Sonntag, 20. Dezember 2020, 09:30:42 MEZ hat 'Oliver Seitz' via jallib <jal...@googlegroups.com> Folgendes geschrieben:


Oliver Seitz

unread,
Dec 20, 2020, 4:06:08 AM12/20/20
to 'Oliver Seitz' via jallib
Or, the idea of having the lib in a simple file must be given up.

Still, 4 files are better than 28 files. Is this the way to go then?

Greets,
Kiste

Am Sonntag, 20. Dezember 2020, 09:59:57 MEZ hat 'Oliver Seitz' via jallib <jal...@googlegroups.com> Folgendes geschrieben:


Rob CJ

unread,
Dec 20, 2020, 6:41:27 AM12/20/20
to jal...@googlegroups.com
Hi Kiste,

I assume (always dangerous) that not many people would include more large_array libraries so I am OK changing the sample files so that it only includes the library once.

I think one file is always better than 28 so I prefer your solution and include only the large_array.jal library and not the numbered ones.

If your tests do not reveal any problems I am OK changing all sample files so that we also do not get the deprecated warning.

Then I could upload the large_array.jal and the 4 generated libraries - for backwards compatibility - including your python program.

If nobody disagrees then I will do that next week or so.

Enjoy the upcoming holidays!

Kind regards,

Rob



Van: 'Oliver Seitz' via jallib <jal...@googlegroups.com>
Verzonden: zondag 20 december 2020 10:06

Oliver Seitz

unread,
Dec 20, 2020, 7:55:17 AM12/20/20
to jal...@googlegroups.com
Hi Rob,

(I to myself:) RTFM. 

jallib/compiler/jalv2.pdf, page 21: "Note that it is not possible to include the same file multiple times. Once a file is included, it will not be included again."

So, we could have another pragma to allow muliple includes for requesting libraries... or we just live with it that way.

It was right the very project which made me touch the large_array lib, that also let me fall into my own trap just minutes after your first reply. I have byte*3 variables to store there, doing so using more than one large_array...

But if you (and everyone else interested...) are ok with breaking compatibility here, I'd go for it and change the comments as to only include the lib once. I can also save a few lines which should have been checking not to re-define anything.

The broken compatibility is easy to find, as there's a warning which tells you where to look. And it is easy to fix, just comment all but the last includes of large_array and place all the alias' behind that include.  

And then... There is yet another solution... but I have no idea if it's portable enough. On Windows, it's at least unusual:

We could symlink large_array.jal to large_array_1.jal, large_array_2.jal..., so the compiler would simply not know that it includes the same file again. It works that way on linux, I have just tested it. Can github work with symlinks? Or zip-files..?

Greets,
Kiste

Am Sonntag, 20. Dezember 2020, 12:41:28 MEZ hat Rob CJ <rob...@hotmail.com> Folgendes geschrieben:


Rob CJ

unread,
Dec 20, 2020, 9:57:27 AM12/20/20
to jal...@googlegroups.com
Hi Kiste,

As mentioned before I do not think that many people are using more than one large array so I would not bother about the include issue.

Today I updated three sample files (locally) with your library and the ease of use is much better if you only have to include 1 library even when using more arrays. 

So my proposal is to use your version and adapt the required sample files. We even do not need to do that but I think it is better to get rid of the warning since they are part of the release. It does not require much work (nice work to do during the Dutch lockdown 😊).

Attached an overview of the sample files that use large_array and so need an update.  As you can see there is only one sample file that uses 4 arrays but I already updated and tested it locally with your library and it works fine. I also upgraded this sample file with some extra functionality.

If there are people that have objections to this approach let us (Kiste and me) know.

Kind regards,

Rob

Van: 'Oliver Seitz' via jallib <jal...@googlegroups.com>
Verzonden: zondag 20 december 2020 13:53
Aan: jal...@googlegroups.com <jal...@googlegroups.com>
large_array.txt

Rob CJ

unread,
Dec 20, 2020, 10:09:36 AM12/20/20
to jal...@googlegroups.com
Hi Kiste,

One small update. Some libraries (not sample files) also need an update, see attached file.

Kind regards,

Rob

Verzonden: zondag 20 december 2020 15:57
large_array_lib.txt

Oliver Seitz

unread,
Dec 20, 2020, 10:51:41 AM12/20/20
to jal...@googlegroups.com
Hi Rob,

that's not so good. 

If we say, just include the large_array lib once, you can't use more than one of those other libs together. Ok, right now it is not possible as all of the libs use large_array_1 (networking.jal only contains a comment about large_array_3). 

Still, the libraries can't be fixed to be combined in any way if we stick to the only-include-once rule.

This gives me another push to seperate the libs again, or use the symlink variant, or even copies of the library file.

Greets,
Kiste

Am Sonntag, 20. Dezember 2020, 16:09:38 MEZ hat Rob CJ <rob...@hotmail.com> Folgendes geschrieben:


Hi Kiste,

vasi vasi

unread,
Dec 20, 2020, 8:22:47 PM12/20/20
to jal...@googlegroups.com
Lets bring all the people on linux, unix and equivalents! Now is the time.

--
You received this message because you are subscribed to the Google Groups "jallib" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jallib+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jallib/1818251322.2749582.1608479497876%40mail.yahoo.com.


--
Vasi

Oliver Seitz

unread,
Dec 21, 2020, 2:45:24 AM12/21/20
to jal...@googlegroups.com
Hi Vasi,

>Lets bring all the people on linux, unix and equivalents! Now is the time. 


Good idea! And, while we're at it, we can go that little further and make peace on earth, stop all pollution, end all diseases and transform all of those terrible dogs to nice cats. </sarcasm>

I've had a quick look at the compiler source, but it's a very long and complicated text in a foreign language to me... Yet, I presume adding a PRAGMA to allow multiple includes is more than tricky. I doubt if a PRAGMA can even find out in which file it is declared.

So, my favourite options are still

1. One library and four symlinks (and symlinks do exist on windows)
2. Four libraries, each doing one array
3. Four identical libraries, wasting some disk space

Linux is not saint, and windows is not evil. It's just another OS, we have to live with it.

Greets,
Kiste

P.S.: Still, there's a joke coming to my mind...

Microsoft once warned from using free software for warranty reasons. Free software is written by thousonds of little-known people around the world, there's noone you can get hold of to guarantee that everything works flawless. While for the windows products, you know that is is the big company Microsoft that doesn't guarantee that everything works flawless.

vsurducan

unread,
Dec 21, 2020, 2:50:03 AM12/21/20
to jal...@googlegroups.com
There isn't such a thing like "nice cats".  :)

--
You received this message because you are subscribed to the Google Groups "jallib" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jallib+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jallib/456964673.2895106.1608536645986%40mail.yahoo.com.

Rob CJ

unread,
Dec 21, 2020, 5:14:04 AM12/21/20
to jal...@googlegroups.com
Hoi Oliver,

To make things not too complicated why not stick to the 4 libraries? With you solution we still have 3 advantages:
1) 1 library that supports both PIC_16 and PIC_14H so no need for 2 separate files anymore
2) Arrays of more than 2k.
3) Includes are not affected.

Kind regards,

Rob

Van: 'Oliver Seitz' via jallib <jal...@googlegroups.com>
Verzonden: maandag 21 december 2020 08:44

Aan: jal...@googlegroups.com <jal...@googlegroups.com>
Onderwerp: Re: [jallib] Large_array update
--
You received this message because you are subscribed to the Google Groups "jallib" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jallib+un...@googlegroups.com.

Oliver Seitz

unread,
Dec 21, 2020, 8:25:54 AM12/21/20
to jal...@googlegroups.com
Hi Rob,


so here it is. 


I've added some ifs to avoid warnings when defining small arrays on PIC14 cores.


:-D May I point out that it is not 2 files that are obsolete then, but these: 

large_byte_array_1_pic14.jal
large_byte_array_1_pic16.jal
large_byte_array_2_pic14.jal
large_byte_array_2_pic16.jal
large_byte_array_3_pic14.jal
large_byte_array_3_pic16.jal
large_byte_array_4_pic14.jal
large_byte_array_4_pic16.jal
large_dword_array_1_pic14.jal
large_dword_array_1_pic16.jal
large_dword_array_2_pic14.jal
large_dword_array_2_pic16.jal
large_dword_array_3_pic14.jal
large_dword_array_3_pic16.jal
large_dword_array_4_pic14.jal
large_dword_array_4_pic16.jal
large_word_array_1_pic14.jal
large_word_array_1_pic16.jal
large_word_array_2_pic14.jal
large_word_array_2_pic16.jal
large_word_array_3_pic14.jal
large_word_array_3_pic16.jal
large_word_array_4_pic14.jal
large_word_array_4_pic16.jal

Greets,
Kiste




Am Montag, 21. Dezember 2020, 11:14:06 MEZ hat Rob CJ <rob...@hotmail.com> Folgendes geschrieben:
To view this discussion on the web visit https://groups.google.com/d/msgid/jallib/AM0PR07MB6241F4DD4B6D3419B28FD681E6C00%40AM0PR07MB6241.eurprd07.prod.outlook.com.
generate_large_array.py

Rob CJ

unread,
Dec 21, 2020, 12:36:28 PM12/21/20
to jal...@googlegroups.com
Hi Kiste,

I ran the program, compiled 3 sample files of which I tested 2 and it all works perfectly. I also tested it for a very large array of 8k without any problems.

I propose we add both the python script and the large arrays to the release and remove the files you mentioned.

One small question: What is the '\' doing before the $Revision$ ?

Again great work. Shall I do the GitHub commits and changes (remove files from the release) for you?

Kind regards,

Rob

Van: 'Oliver Seitz' via jallib <jal...@googlegroups.com>
Verzonden: maandag 21 december 2020 14:25

Oliver Seitz

unread,
Dec 21, 2020, 12:55:46 PM12/21/20
to jal...@googlegroups.com
Hi Rob!

Glad you could test it working!

Err... The \ before the $ was neccessary in the bash version to not have it read as variable. I just copied the text over from there without thinking ;-)

Attached is the script with the \ removed, also in the generated files.

As I don't have write permission on the repo, I'd be grateful if you could do the commit.

Greets,
Kiste




Am Montag, 21. Dezember 2020, 18:36:30 MEZ hat Rob CJ <rob...@hotmail.com> Folgendes geschrieben:
generate_large_array.py

Rob CJ

unread,
Dec 21, 2020, 1:54:40 PM12/21/20
to jal...@googlegroups.com
Hi Kiste,

Done. They will be part of the next bee-package.

Thanks again for this nice improvement.

Kind regards,

Rob

Van: 'Oliver Seitz' via jallib <jal...@googlegroups.com>
Verzonden: maandag 21 december 2020 18:55
--
You received this message because you are subscribed to the Google Groups "jallib" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jallib+un...@googlegroups.com.

vasi vasi

unread,
Dec 22, 2020, 12:26:40 AM12/22/20
to jal...@googlegroups.com
Well, symlinks can solve a lot of problems (Eagle CAD can be convinced to run under modern Linux distros via symlinks to the more recent libraries and so on...) and provide means to automation.

I would say that today, Windows is an anomaly (and ReactOS, of course), any other OS is UNIX like (or the majority of them). It won't solve all the humanity problems, but is already the main engine of tons of gadgets, appliances, cars, internet, etc., contributing to a better world.

But I enjoyed your last joke.

To view this discussion on the web visit https://groups.google.com/d/msgid/jallib/AM0PR07MB6241D58142D3C494A4D7F6B0E6C00%40AM0PR07MB6241.eurprd07.prod.outlook.com.


--
Vasi
Reply all
Reply to author
Forward
0 new messages