Converting MINI-BASIC in MASM over to C++?

matsp · 05-27-2009, 04:37 AM

I'm still a bit worried about the code size when using gcc to build the code. I was looking at uSTL, which may work better. Not sure if it supports "map" tho, or if it compiles for Windows!

On the project front, I have now implemented the basics to allow long variable names - it allocates space for variables as needed, not based on "there are only 26 variables". It still doesn't actually allow long names as such, but it's just a question of adding a little bit of extra code.

--
Mats

matsp · 05-27-2009, 12:11 PM

And I've now submitted changes to support long variables. It appears to work fine - as usual, I used pitman as the test-code, and that loads and runs correctly.

Note that some variable names will need a keyword to make them work:

Code:

10 fork = 10

will produce an error when trying to run.

Code:

10 let fork = 10
20 print fork

will work.

I had to change a bit of the parsing code, and fix a the compiler::expect function to use match, because the old token_scanner::get_token() function was not able to provide tokens like "X11" or "A2B" - it stopped on any transition from alpha to non-alpha or vice versa. I think the new get_token is actually a bit easier to read and understand, as I could remove a couple of variables too - but it's got a lot more return statements now!

I think this is a good improvement. ]

Edit: I just pushed a new version number, as the format of the new files is different from old ones.
Unfortunately, the current code allows OLD pre-compiled files to be loaded and attempted to run, which falls over, so we probably need to change the version checking in some way that means that we can detect the "oldest version that works" - or perhaps simply say "the version number pre-compiled binaries will have to match" - any thoughts?

Next two things I will do:
1. Optional use of uSTL instead of STL - should produce radically smaller executable - not sure how much right now, but I'd be disappointed if it's more than half it's current size.
2. ANSI escape codes in consolestdio.

--
Mats

Paul Panks · 05-29-2009, 07:08 PM

Looking good so far. Is a final release coming soon?

Paul

phantomotap · 05-29-2009, 08:22 PM

"Is a final release coming soon?"

This is software development. There is no final release; there is only the last release.

"Optional use of uSTL instead [...] half it's current size."

This is a spectacularly bad idea. The uSTL is not a replacement for the STL, copatble with the STL, or even an alias for the STL.

Instead you may as well use `std::vector<???>' for all storage requirements--replacing every other container--, pun `std::vector<??? *>' as `std::vector<void *>', and use the C IO routines directly. At least then you retain some level of portability and isolation, and the source will not give the allusion of being what it isn't.

Soma

matsp · 05-30-2009, 03:08 PM

Whilst it may be that uSTL isn't a plug-in replacement for STL, it is certainly capable of doing pretty close to everything that our current code is doing in STL - I'm still working through the code to make uSTL compile properly (I only just switched the computer on for the first time a little bit ago, so I haven't done ANYTHING on it today). I certainly think it's a better solution than the solution you are suggesting. Particularly since using uSTL means very few changes to the ACTUAL code, whilst your suggestion implies a lot of changes. And it's selectable, so anyone who wants to use STL can still do so [assuming recompile, of course].

I agree on the "final release". I think we are actually looking pretty good at the moment, and I would have no problem with the current version being used more widely.

--
Mats

phantomotap · 05-30-2009, 03:56 PM

"it is certainly capable of doing pretty close to everything that our current code is doing in STL"

NO. IT. IS. NOT.

A `std::vector<std:

air<x, y>>' masquerading as a `std::map<x, y>' is not even in the same universe as what we need.

"I certainly think it's a better solution than the solution you are suggesting."

O_o

That wasn't a suggestion; that was sarcasm.

*shrug*

If you want to waste time adding that as option solely because the resulting binary is a little large go for it.

Soma

matsp · 06-12-2009, 06:44 PM

Well, my wasted time has achieved this (I've just submitted the code itself, however, I will have to add all the USTL code to the local repo first - it's currently in a different directory).

Now for the results:
1. The compiled code is 183KB, instead of 549KB.
2. The speed of execution (simple benchmark) is approx 5x faster than Visual Studio [1], but about the same as gcc with stl.

[1] This is probably because of some feature we can switch off with a #define - I just haven't figured out what (because I've spent 0 time on that).

--
Mats

Sebastiani · 06-12-2009, 10:17 PM

I'd say that's a significant improvement.

matsp · 06-14-2009, 03:55 AM

I have now posted the USTL code inside the Minibasic project.

Note that you still have to build the USTL by itself. I'm going to fix that...

--
Mats

Sebastiani · 06-14-2009, 04:27 AM

OK, thanks.

matsp · 06-14-2009, 05:06 AM

And I've now ACTUALLY added the ustl code - it already had a .hg directory [becuase I used the hg git extension to pull in the code], and I had to recreate it by moving it to a fresh emtpy directory. All done now [I think - at least it said added 134 files, and the repo is about 200KB larger].
--
Mats

Sebastiani · 06-14-2009, 05:57 AM

For some reason I get an error on -fvisibility-inlines-hidden and -Wno-overflow. I couldn't find the latter in my gcc docs (is it a new-ish option?), and the former, well maybe it just got left out of the mingw port of 3.4.2?

EDIT:
Oh, wait a minute. I don't see the switches in the makefile...what the heck? I'll post back as soon as I figure it out.

Sebastiani · 06-14-2009, 06:03 AM

Oh, I see. It's in the USTL makefile. I guess I can just delete those entries from my copy of the makefile (possible side-effects?).

matsp · 06-14-2009, 06:03 AM

The flags are in config.mk - I haven't bothered to fix the warnings occurring in uSTL.

It may be easies to remove flags that cause the offending code.

--
Mats

Sebastiani · 06-14-2009, 06:28 AM

Fixed those, but now I get compilation errors from utuple.h on lines #293 & #294 (ambiguous template specialization).

05-27-2009, 04:37 AM	#376
matsp Kernel hacker Join Date: Jul 2007 Location: Farncombe, Surrey, England Posts: 15,686	I'm still a bit worried about the code size when using gcc to build the code. I was looking at uSTL, which may work better. Not sure if it supports "map" tho, or if it compiles for Windows! On the project front, I have now implemented the basics to allow long variable names - it allocates space for variables as needed, not based on "there are only 26 variables". It still doesn't actually allow long names as such, but it's just a question of adding a little bit of extra code. -- Mats __________________ Compilers can produce warnings - make the compiler programmers happy: Use them! Please don't PM me for help - and no, I don't do help over instant messengers.
matsp is offline

05-27-2009, 12:11 PM	#377
matsp Kernel hacker Join Date: Jul 2007 Location: Farncombe, Surrey, England Posts: 15,686	And I've now submitted changes to support long variables. It appears to work fine - as usual, I used pitman as the test-code, and that loads and runs correctly. Note that some variable names will need a keyword to make them work: Code: 10 fork = 10 will produce an error when trying to run. Code: 10 let fork = 10 20 print fork will work. I had to change a bit of the parsing code, and fix a the compiler::expect function to use match, because the old token_scanner::get_token() function was not able to provide tokens like "X11" or "A2B" - it stopped on any transition from alpha to non-alpha or vice versa. I think the new get_token is actually a bit easier to read and understand, as I could remove a couple of variables too - but it's got a lot more return statements now! I think this is a good improvement. ] Edit: I just pushed a new version number, as the format of the new files is different from old ones. Unfortunately, the current code allows OLD pre-compiled files to be loaded and attempted to run, which falls over, so we probably need to change the version checking in some way that means that we can detect the "oldest version that works" - or perhaps simply say "the version number pre-compiled binaries will have to match" - any thoughts? Next two things I will do: 1. Optional use of uSTL instead of STL - should produce radically smaller executable - not sure how much right now, but I'd be disappointed if it's more than half it's current size. 2. ANSI escape codes in consolestdio. -- Mats __________________ Compilers can produce warnings - make the compiler programmers happy: Use them! Please don't PM me for help - and no, I don't do help over instant messengers. Last edited by matsp; 05-27-2009 at 12:21 PM.
matsp is offline

05-29-2009, 07:08 PM	#378
Paul Panks Registered User Join Date: Jun 2004 Posts: 76	Looking good so far. Is a final release coming soon? Paul
Paul Panks is offline

05-29-2009, 08:22 PM	#379
phantomotap Registered User Join Date: Jan 2008 Posts: 631	"Is a final release coming soon?" This is software development. There is no final release; there is only the last release. "Optional use of uSTL instead [...] half it's current size." This is a spectacularly bad idea. The uSTL is not a replacement for the STL, copatble with the STL, or even an alias for the STL. Instead you may as well use `std::vector<???>' for all storage requirements--replacing every other container--, pun `std::vector<??? >' as `std::vector<void >', and use the C IO routines directly. At least then you retain some level of portability and isolation, and the source will not give the allusion of being what it isn't. Soma
phantomotap is offline

05-30-2009, 03:08 PM	#380
matsp Kernel hacker Join Date: Jul 2007 Location: Farncombe, Surrey, England Posts: 15,686	Whilst it may be that uSTL isn't a plug-in replacement for STL, it is certainly capable of doing pretty close to everything that our current code is doing in STL - I'm still working through the code to make uSTL compile properly (I only just switched the computer on for the first time a little bit ago, so I haven't done ANYTHING on it today). I certainly think it's a better solution than the solution you are suggesting. Particularly since using uSTL means very few changes to the ACTUAL code, whilst your suggestion implies a lot of changes. And it's selectable, so anyone who wants to use STL can still do so [assuming recompile, of course]. I agree on the "final release". I think we are actually looking pretty good at the moment, and I would have no problem with the current version being used more widely. -- Mats __________________ Compilers can produce warnings - make the compiler programmers happy: Use them! Please don't PM me for help - and no, I don't do help over instant messengers.
matsp is offline

05-30-2009, 03:56 PM	#381
phantomotap Registered User Join Date: Jan 2008 Posts: 631	"it is certainly capable of doing pretty close to everything that our current code is doing in STL" NO. IT. IS. NOT. A `std::vector<std:air<x, y>>' masquerading as a `std::map<x, y>' is not even in the same universe as what we need. "I certainly think it's a better solution than the solution you are suggesting." O_o That wasn't a suggestion; that was sarcasm. shrug If you want to waste time adding that as option solely because the resulting binary is a little large go for it. Soma
phantomotap is offline

06-12-2009, 06:44 PM	#382
matsp Kernel hacker Join Date: Jul 2007 Location: Farncombe, Surrey, England Posts: 15,686	Well, my wasted time has achieved this (I've just submitted the code itself, however, I will have to add all the USTL code to the local repo first - it's currently in a different directory). Now for the results: 1. The compiled code is 183KB, instead of 549KB. 2. The speed of execution (simple benchmark) is approx 5x faster than Visual Studio [1], but about the same as gcc with stl. [1] This is probably because of some feature we can switch off with a #define - I just haven't figured out what (because I've spent 0 time on that). -- Mats __________________ Compilers can produce warnings - make the compiler programmers happy: Use them! Please don't PM me for help - and no, I don't do help over instant messengers.
matsp is offline

06-12-2009, 10:17 PM	#383
Sebastiani Guest Join Date: Aug 2001 Posts: 5,025	I'd say that's a significant improvement.
Sebastiani is offline

06-14-2009, 03:55 AM	#384
matsp Kernel hacker Join Date: Jul 2007 Location: Farncombe, Surrey, England Posts: 15,686	I have now posted the USTL code inside the Minibasic project. Note that you still have to build the USTL by itself. I'm going to fix that... -- Mats __________________ Compilers can produce warnings - make the compiler programmers happy: Use them! Please don't PM me for help - and no, I don't do help over instant messengers.
matsp is offline

06-14-2009, 04:27 AM	#385
Sebastiani Guest Join Date: Aug 2001 Posts: 5,025	OK, thanks.
Sebastiani is offline

06-14-2009, 05:06 AM	#386
matsp Kernel hacker Join Date: Jul 2007 Location: Farncombe, Surrey, England Posts: 15,686	And I've now ACTUALLY added the ustl code - it already had a .hg directory [becuase I used the hg git extension to pull in the code], and I had to recreate it by moving it to a fresh emtpy directory. All done now [I think - at least it said added 134 files, and the repo is about 200KB larger]. -- Mats __________________ Compilers can produce warnings - make the compiler programmers happy: Use them! Please don't PM me for help - and no, I don't do help over instant messengers.
matsp is offline

06-14-2009, 05:57 AM	#387
Sebastiani Guest Join Date: Aug 2001 Posts: 5,025	For some reason I get an error on -fvisibility-inlines-hidden and -Wno-overflow. I couldn't find the latter in my gcc docs (is it a new-ish option?), and the former, well maybe it just got left out of the mingw port of 3.4.2? EDIT: Oh, wait a minute. I don't see the switches in the makefile...what the heck? I'll post back as soon as I figure it out. Last edited by Sebastiani; 06-14-2009 at 06:00 AM.
Sebastiani is offline

06-14-2009, 06:03 AM	#388
Sebastiani Guest Join Date: Aug 2001 Posts: 5,025	Oh, I see. It's in the USTL makefile. I guess I can just delete those entries from my copy of the makefile (possible side-effects?).
Sebastiani is offline

06-14-2009, 06:03 AM	#389
matsp Kernel hacker Join Date: Jul 2007 Location: Farncombe, Surrey, England Posts: 15,686	The flags are in config.mk - I haven't bothered to fix the warnings occurring in uSTL. It may be easies to remove flags that cause the offending code. -- Mats __________________ Compilers can produce warnings - make the compiler programmers happy: Use them! Please don't PM me for help - and no, I don't do help over instant messengers.
matsp is offline

06-14-2009, 06:28 AM	#390
Sebastiani Guest Join Date: Aug 2001 Posts: 5,025	Fixed those, but now I get compilation errors from utuple.h on lines #293 & #294 (ambiguous template specialization).
Sebastiani is offline

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Converting textBox1->Text into a basic string.	azjherben	C++ Programming	5	06-07-2009 08:27 PM
[ANN] New script engine (Basic sintax)	MKTMK	C++ Programming	1	11-01-2005 10:28 AM
what are your thoughts on visual basic?	orion-	General Discussions	16	09-22-2005 04:28 AM
VC++ 6 & MASM (eek)	ahluka	C++ Programming	2	07-16-2005 10:00 AM

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode