|
Post by Pjot on Jan 29, 2014 20:29:48 GMT 1
All, Sometimes I receive complains that the binaries created by BaCon are still quite large. Reason is, that some of the functions are always compiled into the binary, whether these functions are actually used or not. (This is not the case for statements - the code for statements is added while parsing the program.) So I have changed the compile scheme of BaCon a little bit. Now, first all functions are put into an external archive, and only in case a function is used by the converted program the linker will add it into the final binary. If this archive is not there, BaCon will create it first and then compilation and linking takes place. In subsequent compiles this same archive will be used. The result of this is, that a simple "Hello world" program decreases in size on my system from 55188 bytes to 16487 bytes, which is about 30% of the original size. A 'strip' can decrease the size even more. Another nice consequence is that the compile time decreases drastically. Furthermore it looks more professional (but who cares about that ) For now I only have adapted the shell versions. As I am not really sure if this is the way to go, I am happy to hear any comment! BR, Peter
|
|
|
Post by vovchik on Jan 29, 2014 21:38:14 GMT 1
Dear Peter, Something wrong with the permissions on the /new and /beta dirs. cannot access them at the moment - it may be that you are busy at work there. With kind regards, vovchik
|
|
|
Post by Pjot on Jan 29, 2014 22:07:19 GMT 1
Hi vovchik, Strange, now I cannot reach it either??? Must be a problem with my ISP, I will kick them tomorrow But you can try my recently instantiated fossil repository instead. You can do the following: This should give you the latest versions also. BR, Peter
|
|
|
Post by vovchik on Jan 29, 2014 23:10:09 GMT 1
Dear Peter,
I am new to fossil, and I downloaded and installed the required package. When I try to invoke the fossil program with the fossil command, I get:
fossil: unknown repository: fossilrepos.sourceforge.net/srv.fsl/144/bacon
although I can browse the site and get bacon.bac, bacon.sh and bacongui files from the "Files" section. I can also log in as anonymous (with hex password) but do not know wht advantages this has. Any advice?
With kind regards, vovchik
|
|
|
Post by alexfish on Jan 30, 2014 2:14:10 GMT 1
Hi Peter looks good on paper , how will it pan out with hug ,, PS Some professionals in terms of computing seem gets stuck in the MUD and never seem to get out of it >> usually the one that are stuck in the Mud Scream loudest . the day I have to abide by those professionals I get my BBC out of the Closet. or perhaps the Etch A Sketch. BR Alex
|
|
|
Post by Pjot on Jan 30, 2014 8:19:01 GMT 1
Hi vovchik, The directory basic-converter.org/beta/new/ seems to be reachable again. For fossil, it seems Firefox has the nasty habit of cutting off the "http://" part. So it is: BR, Peter
|
|
|
Post by bitvast on Jan 30, 2014 9:37:25 GMT 1
Hi Peter, this sounds great. I'm not so much concerned with the size of binaries, the reduced compile time does it for me.
Why is that? is it because it's a less reliable process?
|
|
|
Post by bigbass on Jan 30, 2014 18:40:37 GMT 1
Hello Peter I see all progress as good and welcomed sometimes the details of doing something as standard operations should be kept easy and error proof maybe just a command line option that allows for the reduced binary size? that would allow fast operation as standard and the slower compile time and smaller bins as an optional way I think that this is a much welcomed option though The reason I suggested optional is I had a compile error with this code snippet Xlibgrandchild.bac using the ./bacon.bash way (with the new beta) and it compiles correctly with bacon 2.4.0 though looks like PRAGMA isn't being included ? Joe
|
|
|
Post by Pjot on Jan 30, 2014 20:09:52 GMT 1
bigbass: you are right, there was a problem with PRAGMA, it did not include the linker flags into the Makefile, but this should be solved now - please look into beta.basic-converter.org/new/ for the latest. As optional feature it would become difficult, because the structure of BaCon has undergone a huge change... bitvast: not less reliable, but the compilation process gets more complicated. The new approach has its benefits, but for somebody not used to C, it may look confusing. BR, Peter EDIT: again there seem to be problems with the beta directory. I have attached the latest to this thread. Attachments:bacon.tar.gz (96.6 KB)
|
|
|
Post by bigbass on Jan 30, 2014 21:16:28 GMT 1
Hey Peter Thank you for taking the time to test the simple example snippet I posted It compiles cleanly and works on my 32 bit box now and the reduced binary size is very impressive thanks again for BaCon it has made coding fun It still amazes me how much can be done with BaCon it keeps getting more powerful! Joe
|
|
|
Post by konaexpress on Feb 1, 2014 0:35:51 GMT 1
Sounds cool and thanks for all the hard work Peter!
John
|
|
|
Post by Pjot on Feb 2, 2014 13:38:21 GMT 1
All, The transition towards the new compile schema for all versions is finished. Please let me know if you run into problems! Enjoy, Peter
|
|
|
Post by vovchik on Feb 2, 2014 16:18:01 GMT 1
Dear Peter,
Thanks. It seems to be working nicely. The only thing I observed is that the Makefile leaves behind (does not remove) itself and bacon.a, even though you have the appropriate rm instructions in the Makefile. Don't know why.
With kind regards, vovchik
|
|
|
Post by Pjot on Feb 2, 2014 16:38:35 GMT 1
Hey vovchik, For 'bacon.a', this is the static archive containing the separate BaCon functions. It is left behind so subsequent compiles do not need to compile this over and over again. The linking just takes the objects from this archive where necessary. Therefore, subsequent compiles are faster. This archive also contains a version check, so with new releases it can verify if a recompile of the archive is required. This can be accomplished by using the new '-a' flag. The 'Makefile' was left behind intentionally. You can always run a 'make clean' or 'make' manually, to cleanup or recompile Not sure if this is a good idea though. Maybe it can be removed after all. BR, Peter
|
|
|
Post by Pjot on Feb 3, 2014 19:55:16 GMT 1
Hi vovchik,
On second thought it only seems reasonable to keep the Makefile when the program was compiled using the '-p' flag (preserve). Because only then the sourcefiles are still available, and a manual 'make' has a meaning.
So now BaCon also will delete the Makefile after each convert/compile (unless the '-p' flag was provided, as just mentioned).
Still, 'bacon.a' will remain on disk, so subsequent compiles will be faster and resulting binaries will be smaller. It can be recreated by adding the '-a' flag.
Regards Peter
|
|