Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Feb 6, 2013 3:33:51 GMT 1
Maybe in ScriptBasic but not when it causes the multiplication of syntax for esthetic's sake. I wish you would have been more clear with the trade offs aspect of this enhancement before raising the bar falsely.
|
|
|
Post by Pjot on Feb 6, 2013 7:23:30 GMT 1
Well, I didn't know you enjoyed looking at the generated C code. For the BaCon user, it doesn't really matter how the C code looks like, as long as he or she can make a program in a BASIC-style. The '&' string concatenator sure makes BaCon more BASIC-ish, don't you think? BTW I have never raised any bar, not to speak of raising a bar 'falsely'. But let me ask you: how would you convert the '&' operator into C? There is no way getting around the strcat(x, y) function I would say. If you have a better idea, please let me know BR, Peter
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Feb 6, 2013 17:24:38 GMT 1
I wish I never brought the & subject up in the first place. I won't be using it for generating my Bacon code.
The C interface enhancements are something you can be proud of. I can't say the same for the & effort.
|
|
|
Post by Pjot on Feb 6, 2013 21:37:06 GMT 1
Well, '&' is just another way of writing strcat(). In fact, it relies on the CONCAT$ macro, which allows multiple arguments to strcat(). The '&' operator is just one step further away from C syntax. But there are more constructs like this, for example, the LEN function is another way of writing strlen(), the INSTR function is another way of writing strstr(), etc. You may find all this disappointing, but BaCon actually *is* a BASIC-to-C converter, or, to put it in your own legendary words, a preprocessor to a compiler. How else would you envision the conversion of the '&' operator? Can you give an example of how the resulting C code should look like? Anyway, I actually start enjoying the convenience of the '&' infix concatenator even more. But then again, I like easy and lazy code - that's one of the reasons why I started the BaCon project in the first place. ;D Cheers, Peter
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Feb 7, 2013 3:00:44 GMT 1
Peter,
You keep missing my point. You have the best solution possible for a Basic to C translator. Why would you code and promote something that is less efficient? I think the & is a great way to concatenate a series of string elements but not at the cost of injecting duplicate code for visual convenience.
If you would have been able to create the same code you do with the CONCAT$() version by substituting & with , and wrapping it in a CONCAT$() function (the opposite of what I did to create bacon_nocat.bac) then you would have accomplished what I thought you did. If you can under program control reverse what I did manually, I will jump back on the & bandwagon again.
John
|
|
|
Post by Pjot on Feb 7, 2013 14:14:39 GMT 1
Why would you code and promote something that is less efficient?
I don't see how nested concatenation is less efficient? Is your issue simply that you don't like nested functions? From performance point of view there is no difference; in fact, it might even be slightly faster.
BR, Peter
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Feb 7, 2013 17:58:20 GMT 1
Interesting theory. Just add 10K (binary) of additional code to BaCon and magically it runs faster.
I think you are going to have a hard time selling that story to the CPU.
I put in the effort to do it right so why the lame effort on your part?
RIGHT - The resulting user binary should be the same if you use bacon or bacon_nocat.
|
|
|
Post by Pjot on Feb 8, 2013 15:40:54 GMT 1
Thanks for your time... Best regards Peter
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Feb 14, 2013 8:41:11 GMT 1
jrs@laptop:~/BaCon/B29/release/P1$ time ./bacon bacon.bac Converting 'bacon.bac'... done. Compiling 'bacon.bac'... done. Program 'bacon' ready.
real 0m9.111s user 0m7.072s sys 0m0.480s jrs@laptop:~/BaCon/B29/release/P1$ time ./bacon_nocat bacon_nocat.bac Converting 'bacon_nocat.bac'... done. Compiling 'bacon_nocat.bac'... done. Program 'bacon_nocat' ready.
real 0m10.675s user 0m10.049s sys 0m0.504s jrs@laptop:~/BaCon/B29/release/P1$ ls -l total 1732 -rwxrwxr-x 1 jrs jrs 471047 Feb 13 23:27 bacon -rw-rw-r-- 1 jrs jrs 267332 Feb 4 16:16 bacon.bac -rwxrwxr-x 1 jrs jrs 483341 Feb 13 23:27 bacon_nocat -rw-rw-r-- 1 jrs jrs 265787 Feb 4 16:30 bacon_nocat.bac jrs@laptop:~/BaCon/B29/release/P1$
- bacon_nocat.bac uses less code than bacon.bac
- bacon_nocat.bac is 10kb larger than bacon.bac in its binary form
- bacon_nocat.bac is 10% slower than bacon.bac
- bacon_nocat.bac string concatenation is like a rabbit in heat.
If you get a moment, check out my SBx IUP wrapper on the AllBasic.info forum. (inspired by HUG)
|
|
|
Post by Pjot on Feb 14, 2013 9:11:09 GMT 1
When I run the "time ./bacon <prog.bac>" I get different results in subsequent invocations. So you may better run the "time ./bacon" multiple times to get a real view on the performance.
Also your results are troubled by the GCC compilation. Sometimes GCC takes longer, sometimes shorter. Therefore it is better to measure the conversion progress itself and leave out the compilation. So you better use the -n switch, e.g.:
If you run this, say 5 times, both for the normal BaCon version, and for the nocat version, then we can see the difference more objectively.
Thanks, Peter
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Feb 15, 2013 21:03:27 GMT 1
Peter,
You are missing the point again. It's not about the time it takes to compile but what that extra time is needed for. I understand and agree with your initial direction to use the CONCAT$() function in BaCon as the most efficient method of string concatenation. You have mentioned more than a few times that the & was a PITA with a Basic to C translator as flexible as BaCon. (shell script, command line and GUI versions)
My point once again is I don't think you should make BaCon less efficient at the price of esthetics's. It's your project and I'm thankful you're willing to share it with us. I have always held you to high standards based on your past project history.
John
|
|
|
Post by Pjot on Feb 16, 2013 9:46:01 GMT 1
Well, as far as I am concerned you are missing my point. The code is not "less efficient" in terms of performance as you are trying to prove.
The 'Tokenize'-function in BaCon, which primarily was intended to split each line of BASIC code separated by a ':', was adapted so it can parse the '&' symbol as well.
As there is a possibility of using multiple '&' in a row, the 'Tokenize'-function grew into a multipass routine where the resulting code ends up into a nested construction. So it was not my explicit intention to do it like this, it just ended up into the situation of nested functions. And there is nothing wrong with that.
Last two weeks I have been focusing on memory management by adding more intelligence to memory allocations and by rewriting pieces of code. During this process I found that there is an internal limitation in BaCon where recursion only can go to 32 steps deep. This is determined by the global variable 'g_MAX_RBUFFERS'. Of course it can be changed to a higher value, but it always will be limited. Note that C has a similar limitation which is determined by the size of the stack.
Anyway, for a nested CONCAT function, it means that we can only concatenate 32 strings in a row, and this is something which I find to be a restriction. Because the straight CONCAT can concatenate an endless amount of terms. Therefore I have changed the 'Tokenize'-function once again to adapt the '&' operator into a straight CONCAT.
Best regards Peter
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Feb 16, 2013 17:24:37 GMT 1
I still have a small bag of quick fixes I carry around that I still need to deal with someday. Sorry for being so persistent on this but I'm glad it all turned out positive for BaCon in the end.
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Feb 18, 2013 17:30:41 GMT 1
Peter,
Just so I'm 100% on the same page with you, if I catch up with bacon_nocat.bac to the current level, will it produce the same user binary as bacon.bac?
John
|
|
|
Post by Pjot on Feb 18, 2013 19:57:49 GMT 1
Well, it depends In these latest versions I have put in a detector, which can show by which BaCon version the binary was produced. Also note that build30 already uses the string function EXTRACT$, which is introduced in... build30. This lead to a nice cleanup of the BaCon source code versions. In fact, build30 contains such a huge overhaul of source code that I can almost name it to BaCon 2.0. So, you have to perform the following procedure: (1) obtain all BaCon versions from the beta directory(2) compile 'bacon' using either the BASH or KSH version (3) compile 'bacon_nocat' using the same shell version in step (2). Or: (1) obtain all BaCon versions from the beta directory(2) compile 'bacon' using either the BASH or KSH version (3) rename the resulting binary, for example to 'bacon30'. (4) compile 'bacon' again, using 'bacon30' (5) compile 'bacon_nocat' using the same 'bacon30' Now you should get binaries which (hopefully) are binary equivalent. BR, Peter
|
|