|
|
Post by bigbass on Feb 25, 2014 15:18:05 GMT 1
Just a quick reminder there is a new beta version to test out just to keep the thread clean all minor bumps to the beta directory announce here beta.basic-converter.org/These can be huge updates and minor bumps just announce any changes so we can help out testing |
|
|
|
Post by Pjot on Feb 25, 2014 23:02:57 GMT 1
Hey bigbass, Thanks for opening this thread - there's a lot going on behind the scenes. You mention "minor updates", but the updates are huge, though this may not be concluded from the notes in the CHANGES file.  Next to the new compile scheme, where only those functions which are actually needed are taken from a newly created BaCon archive (decreasing the resulting binary size and increasing the performance of subsequent compiles), now also a complete new system for variable type detection was introduced. Previously, all BaCon versions used a file scan system to check for variable declarations. (This scanning is necessary, because BASIC likes to use variables out of the blue, without a previous declaration, but C does not. Therefore, BaCon must know whether code generation for a variable declaration is needed or not.) So, the file scanning caused a lot of disk I/O, and also limited the next step in improving the compile scheme (the separate SUB's and FUNCTION's will be put in their own respective object files). Therefore, last days I have changed the variable type detection from file scanning towards an in-memory detection. For the shell versions, I use a technique to hash variable names. For the BaCon implementations, I use associative arrays. To my own surprise, the conversion performance increased dramatically. On my i7 laptop, BaCon converting BaCon went down from 2.0 seconds to 0.75 seconds, a gain in performance of approx. 67%! Also converting HUG programs now happen in the blink of an eye. The performance of the shell versions has remained more or less the same. Next days I will take time to debug and optimize the new setup. However, I discovered already a few bugs in existing programs, which were not visible in the old file scan technique. For example, conflicting global variable names with similar local variable names, which is not allowed. Also, from now on, any pointer type must attach the asterisk to the type, instead of the variable name. I succeeded in compiling my SDL demonstration programs just by changing the declarations of external pointer types in this way. And there are more big changes to come, I have nice some ideas to improve the structure and performance of BaCon even further! Keep you posted, Regards Peter |
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Feb 25, 2014 23:12:36 GMT 1
Keep this up and you may earn your JIT certification.  |
|
|
|
Post by Pjot on Mar 1, 2014 19:16:13 GMT 1
All, More about what is going on behind the scenes. The transfer to the new variable type detection slowly is getting to a stable situation. The performance gain for the BaCon binary is pretty good. The GUI versions should have the same performance, but these suffer from the GTK event handling, which performs the updating of the progress bar, and slows down everything. I am investigating a decent bypass, so the performance for the GUI versions will be better also. So there was another idea which supposed to increase performance. Normally, BaCon writes generated code to disk directly. But instead of writing the generated code to files, I have tested a change where BaCon writes to memory by the use of ramdisks and memory streams. Surprisingly, there is hardly any performance gain from such a setup. For some programs it was even slower...  ...so I am going to put this idea aside for now. Next thing to look at is putting all SUB's and FUNCTION's into their individual object files. Also I found a bug in the handling of RETURN, in case for example a local string mentioned in a function (INSTR, INSTRREV, EQUAL, LEN, REGEX, VAL) is returned directly, like 'RETURN INSTR(a$, "x")'. This always will return a 0, even if there is an "x" found. A fix for this will be available shortly. Regards Peter PS last week I (re-)discovered the macro language M4. I knew it existed, because 'autoconf' uses M4 macros heavily, however, if I had known the actual power of this language before, I probably would have created BaCon in M4 completely |
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Mar 1, 2014 20:33:41 GMT 1
Personally I would like to see your expertise contributing to a C BASIC like direction. This eliminates the translation step all together. I'm sure it wouldn't be that hard to fill in the holes with C BASIC with BaCon functionality. One thing I have noticed using the C BASIC defines with the SB extension modules I'm working on is that the expanded (defines removed gcc -E) code is much easier to read and follows a consistent structure. I see BaCon morphing in this direction already.
|
|
|
|
Post by bigbass on Mar 3, 2014 20:05:16 GMT 1
Just a quick reminder to Bacon users There is a new BaCon beta version to test out beta.basic-converter.org/so we all can help out with the testing part and provide code examples using the BaCon compiler and the BaCon GUI and any other BaCon goodies * we even abuse the compiler by throwing experimental BaCon code at it and it still compiles correctly Thanks for all the updates Joe |
|
|
|
Post by alexfish on Mar 4, 2014 18:42:51 GMT 1
Compiled exec problem ::
Latest Beta:
baconsh to bacongui , appears that bacon.sh does not move the compiled exec in the 'tmp/' directory to the source directory
BR
Alex
|
|
|
|
Post by alexfish on Mar 4, 2014 20:39:01 GMT 1
I be getting compile errors :: bacongui , have not tested others
IE if have directives I think are the new , here are the headers , that work in 2.5.0
PRAGMA INCLUDE SDL.h
PRAGMA INCLUDE cairo.h
PRAGMA OPTIONS -I/usr/include/SDL
PRAGMA OPTIONS -I/usr/include/cairo
PRAGMA LDFLAGS m SDL cairo
2.5.4 fails to compile , have tried hard code , but then err = can't find .h files
on compile as then getting conflicting types etc etc'
EDIT Compiling BaCon bash as bacon.sh works
Alex
|
|
|
|
Post by Pjot on Mar 4, 2014 22:21:44 GMT 1
Hi Alex,
Thanks for your report - my SDL demo's compile OK, also in BaConGUI.
So, can I see the program which you try to compile, so I can reproduce the error?
Thanks,
Peter
|
|
|
|
Post by alexfish on Mar 4, 2014 22:32:16 GMT 1
Hi Peter it be one of the early SDL demos includes use of cairo , see attached Thanks Alex |
|
|
|
Post by vovchik on Mar 5, 2014 0:42:25 GMT 1
Dear Alex, Have a look at my attachment. I changed two lines and moved the "*" to the end of the TYPE def statement. It compiles and runs with the latest beta...on my machine. With kind regards, vovchik |
|
|
|
Post by alexfish on Mar 5, 2014 5:09:08 GMT 1
Hi Vovchik
Can confirm Rev2 now compiles on latest Bacon beta.
Many thanks
Alex
Peter can save some time on this one for now..
|
|
|
|
Post by bigbass on Mar 5, 2014 5:19:35 GMT 1
Hey Guys yeah two lines 132 and 134 moving the pointer to the end This reminds me to go back and fix all of the code examples I posted with pointers and move them to the end to avoid problems ======================================================= As I stated before there are several ways to code using BaCon here is a brief view of what you can do sometimes we use HUG for easy syntax and commonly used widgets to go from idea to working code quickly sometimes its better to use IMPORT for example in gtk or gdk when you have many widgets and have to include headers sometimes its better to use PROTO when we have code that doesn't have casting like Xlib and cairo and SDL sometimes we can use the goocanvas with GFX this has provided many quality examples too and many more to come Thanks Alex and vovchik sometimes we embed C when the original code was in C to start with and we have to make several low level calls all of these styles meet a need and demonstrate that BaCon is Flexible and can support all these uses all is good and all these ways are for producing working code on BaCon P.S compile time is super fast now Joe |
|
|
|
Post by alexfish on Mar 5, 2014 20:05:54 GMT 1
Hi Joe
Thanks for the post,
As a note for readers here we are talking in terms of programming styles or conventions
Recently there have been posts like "I would like to see more effort put back into BASIC"
As far as Bacon is concerned here is some food for thought.
My first BASIC was BBC Basic ,
but here making some pointers , no pun intended
BBC basic had an in line Assembler , this speeded up functions and gave access to the system
where BASIC bits could not. but not as easy to use as C.
BBC Basic also had commands with prefixes , very much similar to bits you may find in C.
I classify the as the power house. may see that not = BASIC in any fashion.
Here We go
* commands look like this
*ALPHABET
*KEYBOARD
*POINTER
*SOUND
*FlipX
*FlipY
*CHANNELVOICE 1 Percusion-Snare
*FX 0
*FX 100
some plot commands
PLOT &ED,x%,y%
PLOT &04,800,800
For any BASIC to survive is has to adapt and be flexible to user needs , in the UK BBC has been reintroduced in Education establishments,
looks like not much to adapt from that aspect.
BR
Alex
|
|
|
|
Post by konaexpress on Mar 5, 2014 21:04:34 GMT 1
Hey Guys yeah two lines 132 and 134 moving the pointer to the end This reminds me to go back and fix all of the code examples I posted with pointers and move them to the end to avoid problems ======================================================= As I stated before there are several ways to code using BaCon here is a brief view of what you can do sometimes we use HUG for easy syntax and commonly used widgets to go from idea to working code quickly sometimes its better to use IMPORT for example in gtk or gdk when you have many widgets and have to include headers sometimes its better to use PROTO when we have code that doesn't have casting like Xlib and cairo and SDL sometimes we can use the goocanvas with GFX this has provided many quality examples too and many more to come Thanks Alex and vovchik sometimes we embed C when the original code was in C to start with and we have to make several low level calls all of these styles meet a need and demonstrate that BaCon is Flexible and can support all these uses all is good and all these ways are for producing working code on BaCon P.S compile time is super fast now Joe Always wondered why you guys jumped around so much with all these platforms or whatever they are called but was always afraid to ask so I didn't look stupid. Nice to know now.....still not sure but think I get it. Nice work. John |
|
...so I am going to put this idea aside for now.
