| Forum List • Thread List • Refresh • New Topic • Search • Previous • Next  1  |  1. new Rapid-Q compiler plan#937 Posted by: 2003-05-18 09:26:46 | Hi, Guidance, hope that you and your loved ones are safe so far from
the SARS situation! I will pray for your happiness and health!
>I mean I don't understand your fix, according to the asm code you attached. As
>a C programmer, I fully understand unfreed pointer will cause memory leak, but
>I don't know the detail of this problem you found in rq lib and how you fixed
>it.
OK, right. I used a free debugger called Debuggy available at
thefreecountry.com. This time to step through the code and find
exactly where the problem was, was much longer than the time to write
and install the patch(es).
eax and edx are 32bit cpu registers. Think of them as LONG vars like
Dim eax As LONG, etc. although they are like dword (unsigned
integers). The push instructions save the current values on the
computer stack. move edx, 4 is like edx=4. move eax, [A] is like
eax=x where the value x stored at address A is used. x is itself an
address to another location. sub [eax+8], edx is like: subtract 4
from the value stored at x+8. The pop instructions restore the
previous values to eax and edx so everything about the registers is
the same as when we entered the new code.
>This is why I fully agree and support your new RQ compiler project, the world
>still need BASIC, a free, powerful and easy to use BASIC just like RQ!
>Then, what's your first step of the new project? What I could do for it?
Koolbasic started with a trimmed down version. I am trying another
approach, which is to construct the entire framework of all keywords
and qcomponents from the start, where, then, the blanks can be "filled
in". In this framework, I have to complete the work to a point where
then each component is a separate obj module. Then anyone could add
or change or debug existing obj modules, in asm or C, to debug or
develop the framework. On the ground floor, I am constructing a
database of all keywords, their bytcodes that go with them. So some
help would be to take the keywords list, use $option bytecode and make
short programs like:
Dim A as Qedit
See the bytecode for the one line, etc. and so forth.
Anyway, that is part of the work. Thus people could help by sending
me lists like this in .csv format:
COMPONENT;STATEMENT; BYTECODE
QEDIT;DIM A As Qedit;xx xx xx xx xx etc
PRINT;PRINT "Hello";xx xx xx xx xx xx
etc
>By the way, why not post our conversation into Guidance Rapid-Q forum? More
>people should join I think.
OK, you post there too, and I will visit regularly to reply in the
Forum! Thanks!
Greetings, doctor electron
http://www.angelfire.com/space/netcensus/
freepress_at_myrealbox.com using @ instead of _at_. | 2. Byte code? #938 | Thanks for your pray for anti-SARS! Here're 2 death at Shanghai! I donated my one-day salary to the Red-Cross, together with all other colleagues. It's a real war between human being and virus, we must win!
About your new compiler plan ---
You mentioned byte code in a .csv file, doesn't it compile to native code? What does that byte code mean?
For customized Qobjects, we can still use source format, and be included by user program. It will be easier for distributing, unless the author doesn't want to share the source. | 3. Re: Byte code? #940 Posted by: 2003-05-18 15:16:32 | IF you compile a program with the $OPTION BYTECODE, all you get in "program.exe" is byte code, nothing more. Actually, in a regular compile, all you get is one of the libraries with the byte code appended.
Historically, tokens were used to represent BASIC keywords. A token is a single byte where the value = keyword. RQ byte code uses tokens and includes user data, like strings in a program. It seems that a "record" format is used for the byte code like this:
token; offset to next record; data
For example, with END SUB we have always:
0A 05 00 00 00 0B
0A is the token, 05 the offset, and 00 00 00 0B the data.
I have to look more, but I think this is the model for the byte code.
Once you read a record, you know exactly where the next record is by the offset (sort of a length value). BIFF8 in Excel has a similar record format.
Thus, the RQ libraries contain two types of code: The actual routines to implement instructions, like A=5. And a Byte Code interpreter to determine which routines need to be called. It is probably easier to skip the byte code step, since the rc.exe part is simplified (don't need to write byte code) and the libraries are simplified (don't need interpreter).
There are two options. Compile RQ Basic to Assembler, or compile BYTE CODE to assembler. As I organize this project, I will probably wind up doing the former skipping the byte code completely, if I can continue to make progress on all of this. So far, I am well into it. | 4. Re: Byte code? #944 | If not compile to native machine code, but via ASM, why not via C code? Just like BCX does?
We don't select compiling to machine code, in order to avoid the work for creating exe file, assembler can do it for us. But this is the only help an assembler can offer. How about high level data structure and functions? String, math, array, etc., ASM has no such built-in instructions, they must be offered by library routines. C/C++ has all of those and more, machine code optimization. Thus, our options are:
1) Make a real neat and professional compiler, create native code exe file from RQ source directly, without the third party assembler;
2) Make a Basic to C translator, just like BCX, but follow 100% RQ compatible concept and syntax;
I strongly prefer option 2), then, we can concentrate our work to GUI framework. For GUI, hope cross-platform, just like RQ already realized, we still have two options:
a) Write our own library by calling native OS functions, i.e. win32api in Win and GTK or Xwin in Linux etc., really a huuuuuuge work! (Advantage: rather small final exe file size)
b) Use ready-made GUI framework/libraries, like wxWindows etc. (wxBASIC does, Current RQ seems use Delphi components)
This part is what BCX not done, and would be a real challenge for RQ clone makers! | 5. RQ to wxWindows translator #951 | Going on ...
How about an Rapid-Q source to C++ translator based on wxWindows GUI library?
1) Since RQ syntax is very close to a subset of C++, or very easy to convert to C++ source, there should be little difficulty to translate most statements, except GUI components. For instance:
FOR i=0 TO 10 STEP -1 -> for (i=0;i<=10;i--)
IF a=b*(100-c) THEN d=1 ELSE d=2 -> if (a==b*(100-c)) {d=1;} else {d=2;}
TYPE QArrow EXTENDS QCANVAS -> class QArrow :public QCanvas
2) For GUI components, it's very possible to translate to corresponding wxWindows controls, like QForm -> wxForm, QListBox -> wxListBox etc. But this need some wrapping work. Maybe can put these code in separate header files, like qform.h, qlistbox.h etc.
3) wxWindows library has many very useful non-GUI function/objects, like wxString, wxArrayString etc., they could directly map to RQ string, QStringList etc.
4) The main disadvantage is, the wxWindows library is a little bit large size. For instance, small utility programs I ever wrote with MingW32(gcc3.2) will be 1~2MB, after UPX, 300~500kB, just like current RQ exe.
5) If we choose to use gcc for backend compiler, the compile time will be very slow compared with RQ, although compile to byte code is much easier. Anyway, gcc should be the best option if we seek the best cross-platform ability.
6) Every RQ coder can write his own functions/objects/libraries and can share to others by either RQ source or translated C++ source or compiled C++ lib. | 6. Re: RQ to wxWindows translator #952 Posted by: 2003-05-21 06:09:30 |
Hello,
A new RapidQ compiler, with sources available making short and fast executables eventually portable ... Many of us have think/dreamt about that.
My opinion is that a translator to C++ would be the easiest way to do it !
But maybe we could translate it to BCX first and let BCX translate it to C !
BCX accepts C in line code, so adding CLASS capabilities should be possible ?
BCX can be compiled using ??some?? C++ compilers. Using BCX will allow most of us to work on the new compiler and most of the basic work is already done.
http://bcx.basicguru.com/
To obtain UNIX compatibility GTK may be a tool ?
Saying it is one thing, doing it is another.
Jacques | 7. Not necessary to BCX #953 | No obviously advantages to translate to BCX then to C++:
> BCX accepts C in line code, so adding CLASS capabilities should
> be possible ?
BCX only create C code, not C++, adding OO need pure C++ code, nothing BCX can help, if so, why not translate to C++ directly?
Understand RQ source includes 3 parts:
1) Basic statements/keywords, like QBasic syntax
2) OO statements
3) GUI components
Therein, I believe 2) and 3) are the main part. The work load should be greater than 1). BCX has no capability for 2) and 3)
> BCX can be compiled using ??some?? C++ compilers. Using BCX
> will allow most of us to work on the new compiler and most of
> the basic work is already done.
As far as I known, BCX only support LCC-win32, it's a C compiler, not C++. Its already done work is too basic to us, as I said, only part 1).
>
> To obtain UNIX compatibility GTK may be a tool ?
>
Using wxWindows is just in order to take its cross-platform capability. Same code can be used for Win32, GTK, X11, Mac, Motif etc., no need to learn them all one by one. And more important, wxWindows GUI is native look and feel, just like the current RQ. http://www.wxwindows.org | 8. Re: RQ to wxWindows translator #954 Posted by: 2003-05-21 08:04:21 | I can see people have some really interesting and good ideas. What I am tinkering with would involve individual .obj modules for each Qcomponent so only those used in a particular program would be linked. Apparently with C/C++ you do not have this level of control on the linking.
I only have lcc which is very good. For this tinkering, though, I am using MASM32 which is a free package (search for masm32). It has macros already written that do everything you can do in C. Math libs, etc, are all available. Thus, I wonder why go to all the trouble to fool with C where you loose control of how the .exe is written. If you know C, then you already "know" how to write in masm32. With compiled C, when you look at the disassembly, it looks very inefficient, like "someone didn't know what they were doing". This is exactly the case. You may have a value in a register, you know it is there and you just proceed. With C it doesn't know much at all, and has to proceed "defensively" and wastes lots of space and time.
Right now I am learning to "read" bytecode. Then there is the option to write main program directly from the bytecode. | 9. Re: RQ to wxWindows translator #958 | Although MASM has math libs, it's still not clean or short enough to realize a BASIC or C expression, like a=c?(++d):(sin(--d)) etc., in asm source level.
I believe there's no argument for C's easier high level expression/control statements and ASM's high run time efficiency. The problem is just select which one, source level convenience or machine level efficiency, is the most important factor. Anyway, I prefer the former, since C/C++ compiler doesn't lower down the exe efficiency too much. Furthermore, our translator is not so time critical.
If we compile lib functions into separate library files, C/C++ linker also can specify which lib should be linked, although most probably manually. This can be covered by the translator, auto-generate the C++ linker options according to the func/lib called in the BASIC source. | 10. Re: RQ to wxWindows translator #959 Posted by: 2003-05-21 18:46:56 | Yes Guidance, wxWindows looks to be THE best choice. I never read about it before. I spent half of my night reading about wxWindows :)
For the others : see http://www.wxwindows.org/
or get only the 2 megabytes wx helpfile at
http://www.teledisnet.be/web/jph01696/wxchm.zip
wxWindows is 100% free (even for commercial use)
wxWindows is a multi-platforms tool
wxWindows CLASS syntax is close to RapidQ CLASS syntax
Of course Assembler would be faster ! But it wont implement CLASSES,
it will not offer "multi-platform", ...
The last time I wrote something in C, it was in the early nineties :)
Jacques | | Forum List • Thread List • Refresh • New Topic • Search • Previous • Next 1 |
|
|
搜索
论坛
Home
回顶部
g.yi.org Hits:0
