XBLite Compiler: xblite.exe revision 2.41.17

[Guy1954]

Dear Xbliter,

For some time now, you could experiment with revision 16 of the XBLite compiler.

I made quite a lot of experimentation myself to check that I did not break anything
(and, believe me, I did break some trusted code, especially in xsx.dll)

Revision16 had 2 major improvements:
- the GRAB statement for text injection (ie GRAB "text.x")
- the CODE/END CODE.for assembler injection, in addition of the ASM keyword

This was necessary in order to implement the revision 17.

Finally, it's done! Revision 17 can be downloaded at D.'s XBLite Forum.

Enjoy! Guy

The download is attached to the following message:
> 21 October 2015
>
> Dear Xbliter,
>
> Please find here revision 17, a pre-revision of a Unicode
> Revision
> 18 (XBLite's Unicode support).
>
>
> Modifications:
>
>   Source          Description
>   =============   ===========================================
> - xblite.x      - Source formated for a bulk-change
> - xblibcc.asm   - STRING concatenate routine (Unicode-ready)
> - xst.x         - New STRING types + BOM codes
>                   $$STRING == $$ASCII
> - xst.dec       - To replace the xst.dec generated by xst.x's
>                   compilation (maintenance comments)
> - XFORMAT.x     - Corrected 2 bugs
>                   Added format code '0' to right-justify
> numbers
> - xblib.lib     - Has corrected FUNCTION FORMAT$()
> - xsx.x         - Added
>                   . XstUnicodeLen()
>                   Emulates WinAPI lstrlenW in order to be
>                   WinAPI-free and Revision 18-ready
>                   . XstGetFileBOM()
>                   Detects the Byte Order Mask of a file
>                   . XstGetStringTypeBOM()
>                   Gets the Byte Order Mask of a string type
> (NEW)
> - bulk_change.x - global code substitution (for your eyes only)
>
>
> I'm not quite ready to offer a beta version of Unicode
> compilation
> as I'm workin on some corner cases, and I would prefer to work
> from a stable pre-revision as I'm planning to port xblite.x
> thru a
> global code substitution (already working: bulk_change.x).
>
> In the mean time, I'm sending you this revision as an
> anticipation
> of Revision 18.
>
>
> Regards,
> Guy "GL" Lonné

[Guy1954]

Dear Xbliters,

As you know, our compiler xblite version 2.41 revision 17 is a
work in progress for a good year now, and I was expecting to ship
an XBLite compiler which would support Unicode this year.

Well, I'm moving on much slower that I'd like, but I'm quite
satisfied of these areas:
1.the parser discriminates properly the 2 supported STRING
  encodings (legacy ASCII and 16-bit Unicode)
2.the code generator does not break on legacy ASCII and generates
  correct GoAsm code for:
 - UTF-16 LE literals
 - LEN(unicode$) in 16 bit characters vs SIZE(unicode$), in bytes
 - Unicode string concatenate, PRINTing and much more

But the true test will be on applications written only for
Unicode, because revision 17 is still an ASCII application;
Enters Revision 18!

How that so?

Revision 17 is a step towards revision 18, in which
the compiler xblite.x revision 18 will self-compile
in native Unicode by means of xblite.exe revision 17.

This is only possible with the "hybrid" revision 17, which will
compile "Unicode" xblite.x revision 18 and the standard libraries
(xst.x, xsx.x, xio.x...) in "native" Unicode.

To keep it simple, revision 17 is not better than revision 16
(already released) for our current (ASCII) development.
However, revision 17 offers new possibilities for GoAsm code
injection; as a for instance, here is how I emulated (for fun) the
standard function XstCopyMemory (sourceAddr, &dest$, bytes) in
xblite.x revision 17 (compilable with revision 16):

            '-XstCopyMemory (sourceAddr, &dest$, bytes)

'#################################################################
'# r17-Only to test the new CODE statement.
'#################################################################
            ' Copy the hardware information to the SYSTEM_INFO
            ' structure.
            GetSystemInfo (&siSysInfo)

            SELECT CASE TRUE
                CASE (siSysInfo.dwProcessorType < 286)
'=================================================================
' 8 bit processor => movsb
'=================================================================
                 CODE
mov    esi,[EmitString.sourceAddr]
mov    edi,[EmitString.dest$]
jecxz > .is_zero8
rep movsb

.is_zero8
                 END CODE
                CASE (siSysInfo.dwProcessorType = 286)
'=================================================================
' 16 bit processor => movsw
'=================================================================
                 CODE
mov    esi,[EmitString.sourceAddr]
mov    edi,[EmitString.dest$]
mov    ecx,[EmitString.bytes]
shr    ecx,1
jecxz > .is_zero16_01
rep movsw

.is_zero16_01
mov    ecx,[EmitString.bytes]
and    ecx,1
jecxz > .is_zero16_02
movsb

.is_zero16_02
                 END CODE
                CASE ELSE
'=================================================================
' at least a 32 bit processor => movsd
'=================================================================
                 CODE
    mov    esi,[EmitString.sourceAddr]
    mov    edi,[EmitString.dest$]
    mov    ecx,[EmitString.bytes]
    shr    ecx,2
    jecxz > .is_zero32_01
    rep movsd

.is_zero32_01
    mov    ecx,[EmitString.bytes]
    and    ecx,3
    jecxz > .is_zero32_02
    rep movsb

.is_zero32_02
                 END CODE
            END SELECT
'#################################################################

I believe that Coders such as bushpilot and gentski will
appreciate the convenience of this CODE statement, drawn
from my needs as an assembler Noob.

The GRAB statement was also great help in xsx.x in order to
generate "typed" quick sort routines from a single "grabbed"
snippet.

To conclude, revision 17 is not better than revision 16 for
our current developments, but this revision is paving the way
of "Unicode" revision 18, which will support ASCII and
Unicode in the Windows environment.

However, I would appreciate if you put it to the test as I can't
cover all the regressions, in spite of my heavy duty testing.

As usual, this is only an announcement: I will post revision 17 in
the XBLite Forum.

Happy xbliting!
Bye! Guy

[Guy1954]

By the way, by browing the assembler snippet, I could see some glitches and some bugs.
I dare you: can you spot them? (there are several)
Don't worry, it will be corrected in the published version...

Bye! Guy

[Guy1954]

Hi Xbliters,

After some tuning, here is the final inline assembler snippet for XstCopyMemory replacement.
Needless to say that I did not test it for Intels 8086 and 286, since my Tandy computers are long dog gone...

I said it already and I repeat myself here, it's for fun and it won't be part of the official release (well, not just for fun: it illustrates the power of this new CODE statement).
I believe that the CODE statement could be used to implement a suggestion from Greg: execute assembler code taylored to the machine's processor at run-time.
XBLite generates 16 bit code, but most machines are 32 bits and even 64 bits. I even doubt that there are still 16 bits machines now-a-day, with XBLite applications.

"I could be wrong now, but I don't think so!" (from Randy Newman's song: "It's a Jungle Out There")
What say you?

Bye! Guy

            '-XstCopyMemory (sourceAddr, &dest$, bytes)

'#######################################################################

'# r17-Only to test the new CODE statement.

'#######################################################################

            ' Copy the hardware information to the SYSTEM_INFO structure.
            GetSystemInfo (&siSysInfo)

' -------------------------
' esi -> source string
' edi -> destination string
' ecx -> byte count
' -------------------------

                    CODE
    mov    esi,[EmitString.sourceAddr]
    mov    edi,[EmitString.dest$]
    mov    ecx,[EmitString.bytes]

                    END CODE

            SELECT CASE TRUE
                CASE (siSysInfo.dwProcessorType < 286)

'========================================================================

' 8 bit processor => movsb

'========================================================================
                    CODE
; 8 bit crawler
    jecxz > .is_zero8
    cld

    rep movsb

.is_zero8
                    END CODE
                CASE (siSysInfo.dwProcessorType = 286)

'========================================================================

' 16 bit processor => movsw

'========================================================================
                    CODE
; 16 bit walker
    shr    ecx,1
    cld

    jecxz > .is_zero16_01
    rep movsw

.is_zero16_01
    mov    ecx,[EmitString.bytes]
    and    ecx,1
    jecxz > .is_zero16_02

    rep movsb

.is_zero16_02
                    END CODE
                CASE ELSE

'========================================================================

' at least a 32 bit processor => movsd

'========================================================================
                    CODE
; 32 bit runner
    shr    ecx,2
    cld

    jecxz > .is_zero32_01
    rep movsd

.is_zero32_01
    mov    ecx,[EmitString.bytes]
    and    ecx,3
    jecxz > .is_zero32_02
    rep movsb

.is_zero32_02
                    END CODE
            END SELECT

'#######################################################################

[Guy Lonne]

Hi Xbliters.

When using the CODE statement, you must keep in mind that:
1.XBLite can probably do the job at least as well,
2.The injected snippet must be "atomic",
3.The snippet could break in a future release of XBLite's compiler,
4.The snippet must be checked "in context", in the generated .asm.


Let me expand:

1.XBLite can probably do the job at least as well

FOR EXAMPLE:

XBLite only
===========
------------------------------------------------------------------------
VERSION "1.00"
CONSOLE
IMPORT "xst"
DECLARE FUNCTION Entry () ' program entry point

FUNCTION Entry ()

source$ = "This is a test!\n\t9, 8, 7, 6, 5, 4, 3, 2, 1, 0.\nHere
we go!"
bytes = LEN (source$)
dest$ = NULL$ (bytes)

FOR i = 0 TO bytes - 1
dest${i} = source${i}
NEXT i

? dest$
a$ = injected$ ("Press ENTER to exit >")
QUIT (0)

END FUNCTION

END PROGRAM
------------------------------------------------------------------------

XBLite/GoAsm mix
================
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
VERSION "1.00"
CONSOLE
IMPORT "xst"
DECLARE FUNCTION Entry () ' program entry point

FUNCTION Entry ()

source$ = "This is a test!\n\t9, 8, 7, 6, 5, 4, 3, 2, 1, 0.\nHere
we go!"
bytes = LEN (source$)
dest$ = NULL$ (bytes)

CODE
mov esi,[Entry.source$]
mov edi,[Entry.dest$]
mov ecx,[Entry.bytes]

shr ecx,2
cld
jecxz > .is_zero32_01
rep movsd

.is_zero32_01

mov ecx,[Entry.bytes]

and ecx,3
jecxz > .is_zero32_02
rep movsb

.is_zero32_02
END CODE

? dest$
a$ = injected$ ("Press ENTER to exit >")
QUIT (0)

END FUNCTION

END PROGRAM
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

I rest my case...


2.The snippet must be "atomic"

mov ecx,[Entry.bytes] sets a register that is not usually used in
generated code, however, the far-fetched example shows what happens
under the hood:

XBLite only
===========
------------------------------------------------------------------------
VERSION "1.00"
CONSOLE
IMPORT "xst"
DECLARE FUNCTION Entry () ' program entry point

FUNCTION Entry ()

source$ = "This is a test!\n\t9, 8, 7, 6, 5, 4, 3, 2, 1, 0.\nHere
we go!"
bytes = LEN (source$)
dest$ = NULL$ (bytes)

FOR i$$ = 0 TO bytes - 1 ' this is trouble!
i = i$$
dest${i} = source${i}
NEXT i$$

? dest$
a$ = injected$ ("Press ENTER to exit >")
QUIT (0)

END FUNCTION

END PROGRAM
------------------------------------------------------------------------

XBLite/GoAsm mix
================
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
VERSION "1.00"
CONSOLE
IMPORT "xst"
DECLARE FUNCTION Entry () ' program entry point

FUNCTION Entry ()

source$ = "This is a test!\n\t9, 8, 7, 6, 5, 4, 3, 2, 1, 0.\nHere
we go!"
bytes = LEN (source$)
dest$ = NULL$ (bytes)

CODE
mov esi,[Entry.source$]
mov edi,[Entry.dest$]
mov ecx,[Entry.bytes]
END CODE

FOR i$$ = 0 TO bytes - 1 ' resets register ecx => "jne >
end.for.0001.test"
i = i$$
CODE
; bug +++
cmp ecx,[Entry.bytes] ; register ecx is reset
jne > end.for.0001.test
; bug ~~~

movsb
END CODE

NEXT i$$

? dest$
a$ = injected$ ("Press ENTER to exit >")
QUIT (0)

END FUNCTION

END PROGRAM
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

A proof?
=======
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
for.0001.test:
mov eax,d[ebp-56] ;;; i665
mov edx,d[ebp-52]
mov ebx,d[ebp-64] ;;; i665
mov ecx,d[ebp-60]<----------------------REGISTER ECX IS RESET
cmp edx,ecx ;;; i149
jg > end.for.0001.test ;;; i150
jnz > A.2
cmp eax,ebx ;;; i151
ja >> end.for.0001.test ;;; i152
A.2:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@


3.The current CODE could break in a future release of XBLite's compiler

Compare:
=======
test ecx,ecx
jz > ecx_equals_zero

With:
====
jecx z > ecx_equals_zero


So tempting to use ECX for zero-testing instead of register EAX that
needs a prior "test eax,eax", except that ECX is not free to use!


4.The snippet must be checked "in context", in the generated .asm.

The snippet must be checked "in context" as it must flow
seamlessly in the generated .asm. But a self-sufficient snippet
might not be as self-sufficient as it looks when mingled with the
compiler-generated code.


XSEd offers the possible for a visual check, mandatory for the daredevil
that you are:
- Compile source.x (F9)
- Right-click within source.x's body
- Select pop-up menu option "View Assembly File"
- Ctrl+F for "CODE"

=> HOW DOES IT FEEL? (guitar jingle)
How does it feel,
to be on your own?
with no directions home?
like a rolling stone?


CONCLUSION

Assembler CODE injection is great, but never necessary, except
to take advantage of specific features of the running processor.
In that case, CODE is a great addition to the tool chest of
a seasonned Xbliter.


Some say:
"CODE, it is a flower, that spices boring developments
just the way that trouble spices boring lifes".

I say: "No! Who needs trouble? Not me, myself and I!"
And three's already a crowd...

[Chandra MDE]

Hi Guy

Where can I download the latest revision of xblite?

Thanks.

[Guy Lonne]

Hi Chandra,

Good to hear from you.

Before I post a new version of the xblite compiler as per your request,
could you please tell me which new feature was missing in your personal version of XBLite
that prompted you to try release 17?

I'd like to verify if your new way to use XBLite is properly handled by revision 17 of the XBLite compiler.
I have seen too many times "toy" new features braking on real life code.
Better be safe than sorry.

Bye! Guy

--
You received this message because you are subscribed to the Google Groups "xblite" group.
To unsubscribe from this group and stop receiving emails from it, send an email to xblite+un...@googlegroups.com.
To post to this group, send email to xbl...@googlegroups.com.
Visit this group at https://groups.google.com/group/xblite.
For more options, visit https://groups.google.com/d/optout.

-- 
Bye! Guy

[Guy Lonne]

Hi Chandra,

You can download the source xblite.x, which I just posted at the Xblite
Forum.


I just finished testing an installation for xblite release 16,
but I could not upload this setup program because of its size,
neither in the Xblite Forum, nor in the Xblite Google Group.
Too bad...


The compiler xblite version 2.41 revision 16 must be installed
in order to compile revision 17, which handles Unicode.

xblite revision 16 offers new possibilities for GoAsm code

injection; as a for instance, here is how I emulated (for fun) the
standard function XstCopyMemory (sourceAddr, &dest$, bytes) in
xblite.x revision 17 (compilable with revision 16):

' r17-XstCopyMemory (sourceAddr, &dest$, bytes)

'#################################################################
' r17-assume a 32 bit processor
CODE
mov ecx,[EmitString.bytes] ; byte count
jecxz > .is_zero32_end ; LEN(source$) == 0

mov esi,[EmitString.sourceAddr] ; source string
mov edi,[EmitString.dest$] ; destination string

shr ecx,2
jecxz > .is_zero32_01 ; LEN(source$) <= 3
cld
rep movsd ; 32-word shuffle

.is_zero32_01
mov ecx,[EmitString.bytes]
and ecx,3

jecxz > .is_zero32_end
cld
rep movsb ; the very last bytes

.is_zero32_end
END CODE

'#################################################################

I believe that Coders such as bushpilot and gentski will
appreciate the convenience of this CODE statement, drawn
from my needs as an assembler Noob.

The GRAB statement was also great help in xsx.x in order to
generate "typed" quick sort routines from a single "grabbed"
snippet.

However, I would appreciate if you put it to the test as I can't
cover all the regressions, in spite of my heavy duty testing.

As usual, this is only an announcement: I will post revision 16 in

[Guy1954]

Dear Xbliter,

I just posted the latest version of XBLite revision16.

Pour rappel, this is ASCII xblite compiler with 2 additional features:
1. CODE and END CODE, which injects assembler code by bulk-prepending with the keyword ASM
  CODE and END CODE are 2 new XBLite keywords (and therefore recognized by the XBLite compiler)

2.GRAB "file_to_grab", which is an IMPORT statement at pre-compilation time
  GRAB is _not_ a new XBLite keyword but a pre-processing directive.

Note that GRABbing an assembler source file will insert the assembler source between a pair of (CODE, END CODE) for proper compilation.

After heavy testing with my pet program vxbl.x (viXen), I believe that the GRAB directive is able to parse and insert any valid file path:
- assembler file name
- XBLite source file name without directory
- file name with partial directory
- file name with directory prefixed by .\
- file name with directory prefixed by ..\

If you want to contribute to the validation of this new GRAB directive, I would appreciate that you throw a wide variety of strange but valid file paths at GRAB until it breaks.
Inform me and I will return you ASAP a fixed xblite.x that will accomodate your specific need (with GREATTTTT joy!)

Bye! Guy

[Guy1954]

Hi Xbliters,

You know what? I succeeded to break the new GRAB directive!
The patch to correct the bug was just an IF condition change, but I was very proud to "shoot myself in the foot".

I uploaded the corrected xblite.x in the XBLite forum, so that you can get a chance to catch another corner case.

Bye! Guy

BTW, the (CODE, END CODE) is also a pre-compile directive ; when [pre]processed, the resulting XBLite source does not contain any CODE statements, contrary to what I announced (a design decision after heavily testing both implementations).

[Guy1954]

Hi Xbliter,

In order to implement Unicode support in the XBLite compiler, I decided to add 2 pre-compile directives: GRAB and CODE.

Why?

GRAB allows me to clone xblite.x's tried and true ASCII support, and CODE allows me to inject assembler snippets when absolutely needed.
And these two really simplify code re-use.

I just spent a whole week to test, test and test again and I was very satisfied with my latest revision 16 (attached).

However, a Developper is not the best Tester for his/her production. I need your input, not the sound of silence!

Just try them and you will get a sense of what time-savers they can be.

In the mean time, I would appreciate if you could try to use them in legitimate ways that I can't think of, and share your findings and your wishes.
If you need some use cases, I can provide here with some useful ones.

Bye! Guy

[emil_...@yahoo.com]

Nice work  Guy1954 ,

It helps a lot , i can extend CODE/End CODE to add high level asm code.

Emil.

[Guy1954]

Hi Emil,

Nice to hear from an active Xbliter.
Would you mind to share how you put xblite to use?

I just corrected a (rare) bug in the handling of GRABbed file paths.
Please, download the attached version of xblite.x from the XBLite Forum.

Bye! Guy

[Emil Halim]

Hi  Guy,

actually I like developing programming languages , two years ago i was extended the features of xblit basic.

for example , here is ucase demo , the first is the original one , the second is your and i extension

'

'

' #######################

' #####  Ucase$ ()  #####

' #######################

'

FUNCTION  Ucase$ (text$)

x$ = text$ ' string to modify and return

ASM mov esi,[Ucase$.x$] ; string address of 1st character

ASM mov eax,[Ucase$.x$] ; string address of 1st character

ASM sub eax,8 ; string length at stringAddr - 0x08

ASM mov ebx,[eax] ; get string length

ASM   Next:

ASM dec ebx ; point to the next prior character

ASM js > Exit ; jump if sign is negative ebx is < 0

ASM mov al,[ebx+esi] ; put the current character into al

ASM cmp al,'a' ; compare char to 'a'

ASM jb Next ; jump if below to Next

ASM cmp al,'z'  ; compare char to 'z'

ASM ja Next ; jump if above to Next

ASM sub al,0x20  ; convert to upper case

ASM mov [ebx+esi],al ; put al back into string

ASM jmp Next ; jump to Next

ASM   Exit:

RETURN x$

END FUNCTION

'

'

' #######################

' #####  Ucase$ ()  #####

' #######################

'

FUNCTION  Ucase$ (text$)

x$ = text$ ' string to modify and return

 CODE

 ^^

  esi  = [Ucase$.x$] ;string address of 1st character

  eax  = [Ucase$.x$] ;string address of 1st character

  eax -= 8 ; string length at stringAddr - 0x08

  ebx  = [eax]         ; get string length

     @@:

  ebx-- ; point to the next prior character

  js > Exit ; jump if sign is negative ebx is < 0

  al = [ebx+esi]          ; put the current character into al

  cmp  al,'a' ; compare char to 'a'

  jb   @B ; jump if below to Next

  cmp  al,'z' ; compare char to 'z'

  ja   @B ; jump if above to Next

  al -=  0x20               ; convert to upper case

  [ebx+esi] = al ; put al back into string

  jmp  @B   ; jump to Next

 ^^

     Exit:

 END CODE

RETURN x$

END FUNCTION

 as you can see using high level asm make things more easy and understandable.

 btw , i did not rigesterd  yet so i can not log in to download from forum.

keep your good working 

Emil.

 

[Guy1954]

Hi Xbliters.

Here is attached xblite.x, my latest revision of XBLite version 2.41.16.
I'd appreciate if you download this file and use it to recompile your XBLite programs.
I need an OK from the all of you to use this very xblite.x as a starting point for the Unicode version.

Warnings:
1.Make a backup copy of your C:\xblite\bin\xblite.exe: xblite_old.exe
2.Make a backup copy of your C:\xblite\xblite_241_src\xblite\xblite.x: xblite_old.x
3.Overwrite your C:\xblite\xblite_241_src\xblite\xblite.x with the downloaded xblite.x
4.Open the new C:\xblite\xblite_241_src\xblite\xblite.x with XSEd
5.Compile (F9), Link (F10) and Run (F11) => displays "...XBLite version 2.41.16..." in the console
6.Overwrite C:\xblite\bin\xblite.exe with C:\xblite\xblite_241_src\xblite\xblite.exe

Now, I suggest that you add the new keyword STRIP to all of your programs and recompile them.
This new STRIP directive remove dead code: internal function bodies of uncalled functions.
I added STRIP to allow a casual use of the (new) GRAB directive.

I do not expect to have any bug report from you. So, if everything works fine, please let me know.
Thank you for the time you will spend on testing.

Bye! Guy

PS. Just as a reminder, I explain again why I added GRAB and STRIP.
I did so because I believe in the DRY principle. It stands for "Don't Repeat Yourself!".
GRAB "some_snippet.x" allows for code re-use, and STRIP allows the weed away extraneous code.
You can store these snippet in a new directory C:\xblite\grab_bad, which you can share with the XBLite community just like you would do with a DLL.

[Guy1954]

Use rather this xblite.x for compiling with a STRIP directive as I modified it to generate a new mySource_strip.x only if original mySource.x is stripped off the uncalled functions. Sorry about that.

[Guy1954]

Dear Xbliter,

I don't know about you (regretfully), but I experimented with revision 16 of the XBLite compiler,
and attached is the result of this heavy testing: my final version of xblite.x.

The new STRIP directive appeals to me more and more: when the XBLite compiler removes the body of an uncalled function, it is either legitimate (and then prevents compiling dead code), or a mistake (which should be corrected). I tried it on vxbl.x, and I addressed 2 dead functions, which had to be called; a new good habit before shipping new programs especially because the compiler does not STRIP a meticulous calling tree. However, STRIP works wonder on a GRAB statement as it removes all the unnecessary function before compilation. Talking about GRAB, I use it flawlessly even on very convoluted path. But I’m waiting for your inputs, and you might be smarter than me...

Enjoy! Guy

[janton_bcn]

Thanks Guy. I I downloaded all of your code and I will try to understand this important upgrade sooner or later. Because I believe xblite is the best open source compiler ever done I'm working to add features in my spare time. However it's not a finnished work so I can't show anything up to the present day. I hope I will show all my code briefly.

Because I don't really undertand xblite.x code (too difficult to understand for me) I'd better gather with xsed.x code. First I solved a nasty bug that prevents xsed to open 2 filenames with same name. Then I went to subclass TAB in order to show close icon (see screenshot: 1)..very handy tool. Next I added two keys : INCLUDE and  HOOK. INCLUDE keyword adds an external piece of code; HOOK prefixes a function and compiles if and only if it is defined (see screenshot: 2). Next I went to extend functionality of right treeview panel (see screenshot: 3). However, this is not a finnished work as I said before. Next logical step goes to provide an .SKX extension companion file (skeleton file). This file is nothing but a saving of the right panel treeview, so one can open and save all this information at any moment.

Obviously xblite.x upgrade code is more important than this because this is the heart of the system so please take courage to continue coding, Your upgrade is truly important.

Sincerely, Joan.



 

[Emil Halim]

Nice work Joan.

[David Szafranski]

Hi Emil,

Your extension to make asm coding easier is very nice. Would you be willing to share with
me your changes to the compiler to accomplish this?

thanks,

David

[Emil Halim]

Hi David

It's my pleasure to share it with you all of users.

actually i did not any changes to the compiler itself, i made my extension as a preprocessor.

that means the extension is a plugins system which consists of DLLs those process the source code to allow new features.

each plugin processes a certain  part of source code with it's own way , finally the source code is ready to compile with the original compiler.

also i was developing this system to extend SphinxC-- language.

need some times to finishing it ,then i will post it.

thanks,

  Emil.