O2 Source ?

[JRS]

Charles,

Where is the maco() function defined. I'm looking over o2sema.bas and see this function used a lot but I couldn't find where its defined.

John

[Charles Pegge]

Hi John,

maco(record,field) is a database record array for all defined entities. This includes keywords, types, variables, functions, classes, macros, everything. That is why you see it very frequently.

Most of these things are defined in o2glob.bas.

Very brave of you to examine the source code 

Charles

[JRS]

Very brave of you to examine the source code

I'm just trolling for show stoppers before I make any serious attempts at converting O2 to SB.

It is going to take a bit more work to determine what is an array and what is a function/sub when both use (). I guess I'm spoiled with SB using [] for arrays.

[Charles Pegge]

The o2lex functions are probably the most challenging because they are mainly in assembler. What they do is quite simple but they have to be fast.

[JRS]

As long as this is nothing more than converting text to a binary file format with no external tools, things should go smoothly. What I have seen so far isn't that hard to convert to SB.

I'm counting on that moving to Linux is going to be a run time code tweak and the logic for converting O2 Basic code to it's final executable state won't change much. With that said, I should be able to create a O2 compiler framework in SB and generate platform specific executables from any OS that SB runs under. (Windows, Linux and Mac 32/64 bit)

Things SB programmers don't need to be concerned with and learn to appreciate.

• Memory management.
• Dynamic strings (available memory is the only string variable size limitation)
• Typeless variables. (type is determined at time of use)
• Dynamic arrays (no need to DIM anything)
• Mixed associative and traditional array usage. (build complex structures easily)
• Extensibility (shared objects/DLL) with a tight integration with the core scripting engine API
• Thread safe by design with inter thread variable sharing with locking support

I could go on but these are at the top of the list.

[Charles Pegge]

With 757K of source code it is a major project! I wish I could make it shorter.

Quite a number of the functions written in Assembler could be rewritten in Basic with minimal loss of performance.

Select / switch / case constructs produce very efficient code - as good as doing the same in Assembler.

Charles

[JRS]

I'm not looking at changing any of the flow of O2 IF I decide to take a stab at converting O2 to SB. I'm assuming that it really doesn't matter if the text is Basic or ASM, your assembler/linker does it's magic and out pops a executable. It's a string processing job as I see it. If I'm missing something, please let me know so I don't waste a bunch of time on this effort.

[Charles Pegge]

Yes you are right John, It's a string job all the way down to machine code and the PE file (or ELF file for Linux). The only thing you can't do in SB is direct execution in memory.

I do it in these stages:

Basic to Assembler
Assembler to machine script
machine script to binary

It is easier to keep everything in text form until the final stage, though it is technically possible to go directly  down to binary.

I noticed that SB does not have MKL() and similar functions though these are mentioned as planned in the manual. You will have to construct binary encodings using asc() / chr().

Charles

[JRS]

I noticed that SB does not have MKL() and similar functions though these are mentioned as planned in the manual. You will have to construct binary encodings using asc() / chr().

I'm thinking it would be easier just to create a SB extension module in C to deal with any low level stuff that would be a pain in the ass in Basic to do.

Where do you suggest I start with the conversion?

[Charles Pegge]

I would start by investigating Oxygen.bas. It will give you a feel for how the compiler is organised.

For the self-compile I already had the run-time library RTL32.inc (from o2runt). Then I ported o2link, then o2glob and o2lexi. These 3 files are sufficient to make the machine script to binary stage. Then the other files were ported working down from the top of list and ending with o2assm. This is the least bumpy ride for test and debug.

The major part of the effort is testing all the components and flushing out bugs. Some of them, in my experience will be quite subtle and won't be obvious by looking at the code alone.

Charles

[JRS]

The only thing you can't do in SB is direct execution in memory.

   I remember when there was a SBO2 directory out of examples, executing O2 scripts in memory.

I think SB with its internal preprocessor support could make a nice debugger.

My interest in this fork of O2 is to provide a means to roll your own compiler from anywhere for anything.

Scriptpiler 

[JRS]

Charles,

Do you see any problems with the asm/end asm being a string until the assembler looks at it?

Code: [Select]

 asm = """
    mov ecx,[p]                        'ADDRESS OF CODE
    cmp dword ptr [ecx],&h00905A4D     'DOS  `MZ` SIGNATURE: `MZ` 90 00
    jnz npef                           'SKIP IF NOT PE
    add ecx,&hff0                      'MOVE o2 ENTRY POINT
    npef:                              '
    mov ebx,[psysfuns]                 'BASE ADDRESS OF RUNTIME FUNCTION TABLE
    call ecx                           'CALL CODE
    mov [function],eax                 'RETURN DATA
  """

I understand that within the ASM code there may be variables references defined by the compiler Basic code.

Code: [Select]

    npef:                              '
    mov ebx,[""" & psysfuns & """]  'BASE ADDRESS OF RUNTIME FUNCTION TABLE
    call ecx                                  'CALL CODE


[Charles Pegge]

Yes the assembler receives the Basic output as a single string of text.

Each variable is converted to a register and an offset like [ebx+100] before it is passed to the assembler. [ebx+100] representing the location of the variable.

Charles

[JRS]

Charles,

Unfortunately O2 is too Windows specific at this time to attempt a meaningful translation to SB. There is still too much FreeBASIC specific code in the source to ignore as you transition to self compile.

I may have another look at this when you have a 64 bit Linux version to play with.

As much as I like what your doing with O2, resorting to Windows as the only target is too debilitating.

John

 

[Charles Pegge]

Hi John,

These are the core calls to the operating system.

Code: OxygenBasic

1.  
2.  'def LoadLibrary           [ebx+024]
3. 'def GetProcAddress        [ebx+040]
4. 'def FreeLibrary           [ebx+032]
5.  def SysAllocStringByteLen [ebx+160]
6.   def SysFreeString         [ebx+168]
7.   def GetModuleHandle       [ebx+440]
8.   def GetGetCommandLine     [ebx+448]
9.   def GetExitCodeProcess    [ebx+456]
10.   def ExitProcess           [ebx+464]
11.   def CreateFile            [ebx+480]
12.   def ReadFile              [ebx+488]
13.   def CloseHandle           [ebx+496]
14.   def MessageBox            [ebx+472]
15.   def MessageBoxW           [ebx+504]
16.   +
17.   WriteFile
18.  
19.  
20.  

Apart from these there is the more complex task of building an ELF header to replace the PE header. o2hdrs.bas deals with this aspect. I need to study some real ELF  headers to get a clear picture of how they are used. But it promises to be a lot cleaner than PE.

And in conjunction with this, resource building will also be totally different. An area I have not researched yet.

Charles