LuxAsm - the luxurious assembler

I was just browsing through the mail archive and I wondered if there is any plan of how to go about this project?
One thing which comes to mind is, clarifying the license issue BEFORE any actual code is written, to make sure that all authors agree on what they are doing and how it will be distributed.
Second thing is, is there anybody here who already has done some wiork with Xlib in any language?
Maybe it would be a good idea to write a simple hello world programm in i.e. NASM to see what is asbolutely essential for a basic Xlib program. In parallel the basic discussion can be held on what features the assembler should support, the linker and of course the GUI.
Writing out a plan is a good idea to keep the project running and give each member an idea on what status the project currently is.

For the main assembler, the license would probably be GNU GPL -- especially as this would allow imports from RosAsm.

Though for the libraries a mixture of the GNU LGPL, X license, BSD and public domain would be better -- especially if we want commercial use to be viable.

The license for each library function should be up to the coder of the function, though seperating libraries depending on license would be a good idea.

Of course, a large standard library is necessary for the success of the project -- in my opinion the success of Java is due primarily to this issue not any language superiority. Ie. we would need a library as extensive as Java's to really make a splash in the assembler world. This could be achieved by simply collating all the assembly snippets out there (with proper credit attached, of course). Though higher level functions -- especially GUI ones would have to be written from scratch.

[ I would provide a hello world example, but I am on Solaris currently and cannot access my Linux assembly library or test it -- coding from memory would likely introduce errors which would cause more confusion than otherwise. On the other hand I seem to remember a similar example to what you requested (but written in AT&T assembly) in the 'Assembly Programming Journal' see http://asmjournal.freeservers.com/ -- hope that it will help. ]

C
2004-02-03

> I was just browsing through the mail archive and I wondered if there is any plan of how to go about this project?

Well, it's still under discussion but I've proposed a basic idea about making it "modular" from the ground up...not having libraries under Linux / X would be exceedingly difficult that we're going to have to concede "library support" on practical grounds, even if RosAsm's lack of library support wasn't one of the chief failings that most people have about it that it's probably best NOT to copy it on those parts...

My essential idea is to have a "base module" which is just the IDE and then everything else from then on is a "module" that gets picked up from a "modules" folder...the assembler, linker, debugger, etc. are all just "plug-in modules" to a basic IDE...basically, if we're going to have modular / library support, I'm thinking we go to the other extreme and use it from the ground up...

The benefits being that "modules" are easily plugged-in and replaced, can be developed separately and even allows third-party projects to work on their own modules...special "filter modules" can interface between the LuxAsm IDE and other tools like, say, NASM (the "filter" is just a plug-in module that handles translating stuff from the IDE into a NASM command-line and then translates back errors into IDE terms :)...

The cost of this very, very flexible architecture, though, is some more up-front work on specifying an "interface" for modules...I personally think the cost of a little extra time there, is more than made up for, though, in having some incredibly _tough_ and highly flexible foundations on which to hold the project...

"Start as you mean to go on" and all that :)

> One thing which comes to mind is, clarifying the license issue BEFORE any actual code is written, to make sure that all authors agree on what they are doing and how it will be distributed.

Agreed; That's why I wrote the support Email to SourceForge, who've suggested I talk with the FSF...I'm pursuing the licence thing...but I already think that simply starting up a _separate_ "Xlib for assembly" project under the original X licence would calrify the licence as well as make things available for, say, the NASM team or whoever should they also want to make use of it...a GPL project like LuxAsm can borrow from X licence and Randy's PD HLA can happily bend the rules for the X licence, as it doesn't place any restrictions other than the copyright on the original Xlib files is kept in comments at the start of the file...

I'm sure that this method solves the issue satisfactorily while keeping things nice and simple licence-wise...plus, being "separate" (which keeps the GPL happy), this "spin-off" project can be used by those who just want "Xlib for ASM" and aren't interested in the LuxAsm or HLA projects...it's actually _more_ "open-source" this way...

But I'd like the clarification from FSF or whoever that this idea actually is valid before I go and create my own separate "Xlib4Asm" project on SourceForge...though technically separate, all work on that project helps towards work on this project and towards helping Randy with his "portable GUI library" (who knows? If LuxAsm were to develop a Windows counterpart in the future, then the work there could contribute back here and so on and so forth...unlike Rene, I do believe we're getting the "open-source" spirit a little more correct than he does ;)...

> Second thing is, is there anybody here who already has done some wiork with Xlib in any language?

Yes; Not a complete application but lots of experimental stuff in C and one or two minor attempts with ASM...I'm not the world's greatest expert and part of joining this project is, in fact, about getting the practice and better knowledge in this area but I'm confident enough that it won't take long to get things working...in fact, Frank's already got his "hello, world" up and running...

Due to my problems getting Linux installed, I'm running behind on this point (and I probably should concentrate on that rather than the homepage but, hey, I like to make webpages! ;) at the moment...that is, it's kind of "mandatory" that I get Linux working to get moving on this project...

> Maybe it would be a good idea to write a simple hello world programm in i.e. NASM to see what is asbolutely essential for a basic Xlib program. In parallel the basic discussion can be held on what features the assembler should support, the linker and of course the GUI.

Actually, though not formalised, this is kind of already happening...Frank's been playing around with a "Hello, world" kind of thing and reporting his successes...while I've been throwing in my rough architectural ideas about "modules" and that kind of thing...I do plan to put together some kind of simple "example" document with the basic idea mapped out better for all to look at but was working on a basic homepage and, also, I kind of was waiting for Frank and Yeoh and any others who're joining the project to at least give some kind of "yeah, sounds interesting, tell us more" approval...no sense me writing out a 100 pages on it to find: "oh, didn't I mention? Hated your plan from the beginning" ;)

> Writing out a plan is a good idea to keep the project running and give each member an idea on what status the project currently is.

Totally; An absolutely smashing plan...especially as you know better than most how I'm highly prone to "wander" unless pushed and prodded in the right directions (if people are wondering, I started a project with Gerhard before but it fell apart because I was all over the place and it was only us two to begin with that having one half of the project not really paying attention is a sure recipe for it to screw up...and, yup, I'm still totally feeling guilty about messing that up, Gerhard...it wasn't intentional, I was just badly disorganised and lost the plot there...I think, though, with this project, things will work out much better...we should have perhaps "gone SourceForge" with that other project because, yes, I do find the organisational tools and facilities here are exactly the kind of "focus" I was lacking before...anyway, it's due to being quite pathetic the last time that I'm going to do things properly this time :)...

[quote]
Agreed; That's why I wrote the support Email to SourceForge, who've suggested I talk with the FSF...I'm pursuing the licence thing...but I already think that simply starting up a _separate_ "Xlib for assembly" project under the original X licence would calrify the licence as well as make things available for, say, the NASM team or whoever should they also want to make use of it...a GPL project like LuxAsm can borrow from X licence and Randy's PD HLA can happily bend the rules for the X licence, as it doesn't place any restrictions other than the copyright on the original Xlib files is kept in comments at the start of the file...
[/quote]

If a seperate project is required, how about naming it something like "LuxAsm Library" so it maintains its link with the main LuxAsm project while being clearly under a seperate license (either X License or pure public domain)?

C
2004-02-04

> If a seperate project is required, how about naming it something like "LuxAsm Library" so it maintains its link with the main LuxAsm project while being clearly under a seperate license (either X License or pure public domain)?

Well, it'll be X licence because you can't de-X-ify the Xlib libraries...that is the only restriction, in fact, that the X licence puts on things...you may do whatever you like but you can't drop the original copyright and credit on the original Xlib stuff...otherwise, the X licence is actually effectively the same as PD...copyright is solely retained so that people can't grab your work, change it a bit and then claim it's all their own work...hence, it's just like PD but the "credits" on the original work must remain and you can't de-X-ify it...

Also, just in case there's confusion, these libraries are the "Xlib" libraries that are used to interface with X-Windows...what we're essentially talking about, comparing this to Windows, is creating a "windows.inc" file with all the API functions and types and such...but this is the X-Windows equivalent to that...

Xlib, the library, is itself already written and there exist C header files for accessing it...all that's missing - which is why this project is required - is having those C header files in ASM form...

Essentially, you know how hutch put together some "windows.inc" files for his MASM32 package because though there are C Windows header files, most assemblers don't come with such headers? Well, we're talking about much the same work as that but for X-Windows instead...

Unlike Windows, X-Windows has not yet come under the "new wave" stuff of having people create X-Windows assemblers with X-Windows header files already created and X-Windows Iczelion tutorials and such...that "new wave" that happened over on Windows to bring a new generation over to the idea of Win32 ASM programming just has not happened for X-Windows...

LuxAsm is, in fact, that "new wave"...borrowing from how it worked on Windows, we'll be taking this to Linux...so, this "Xlib for assembly" project is not about creating our own library but creating files to interface with the existing X-Windows libraries (which, like Windows, are where the API is housed :)...

If there will be a "LuxAsm standard library" - something not yet discussed or decided - then that should actually be just fine staying as part of LuxAsm itself under the GPL...

We only need to "release" the Xlib interface files from the GPL as a separate work because such files are appropriate for _other assemblers_ too...top of the list because Randy's already declared and interest - and I've promised to assist him there - is HLA...it requires an interface to X-Windows so that Randy can expand his "HLA standard library" to use GUI elements in Windows and X-Windows at the same time, taking his "portability" feature in HLA into GUI realms, not only console-based applications...

Although, Randy's declared an "interest" in that direction, this stuff is also perfectly appropriate for use with NASM and GAS (in fact, _ANY_ assembler that works on Linux :)...so, it makes sense to "release" this stuff _separately_ from LuxAsm under a relaxed licence to permit this work to simply be "borrowed" by HLA, NASM, GAS, etc. at their discretion (mind you, I say "they" but that actually includes myself when I help Randy with that "portable GUI library"...it actually was my original idea for him to go down that route and said I'd help him so I am tied to that project too...luckily, it should perfectly fit into what I'm doing here and won't start until HLA v2.0 is finished...plus, with Randy's productivity, I'm probably actually only going to be more of an "advisor" on the GUI aspects - making a GUI "portable" requires thought...I've already put that thought in when I was talking to Randy about how it would work so I guess he wants my help on "okay, you seem to have worked this all out already" grounds..."why re-invent the wheel?", as they say (I'm sure Randy _could_ easily do so but seeing as he doesn't need to when I've volunteered to help, it would be silly to refuse ;) - and a means to "parallelise" the work to get it done quicker)...

So, actually, splitting it off separately isn't just a "GPL avoidance" tactic...it _is_ actually something that's legitimately "separate" because _all_ Linux assemblers can benefit from the work...I think it's best given a "neutral" name like "Xlib support files for assembly programming" (Xlib4Asm as a possible "UNIX name" :)...

As to some "LuxAsm library" in a kind of "standard library" way, it's not even been discussed or decided if we should not just borrow ideas from Rene but from Randy too...I wouldn't be opposed to the idea at all...it's just an awfiul lot of work...something to "defer" until a rainy day, perhaps?

Mind you, here's one mad idea...LuxAsm can not only be written in LuxAsm but if there was a "LuxAsm standard library" then LuxAsm could be written using that library...then, if it should ever be "ported" to a Windows version, we can copy how Randy did things for HLA to get a "portable integrated GUI assembler with standard library support" going at it a different way to HLA...Rene would certainly have headaches from there being _two_ assemblers working on the "new new wave" front...

But, hey, in our "help file", it's only fair that we give mention to the "pioneer" of the "new new wave" by listing Rene and Randy as sources of inspiration...oh, he'd Love that...being both "historical" as helping _others_ move towards the "assembly rebirth" while he's still stuck in the '60s _and_ being listed alongside Randy in the "history books" as an _equal_ "pioneer"...

Understood...

So an Xlib / assembler project would be a series of fairly generic .inc files designed to the mechanically translated to _any_ assembler? That seems a good idea (and one which could well be useful in some of my other projects).

I think a LuxAsm standard library would be a good idea, though releasing in as public domain or LGPL would be needed if we ever want LuxAsm to be used commercially (ie. for games programming, where cutting edge speed is really needed). This could be done on an adhoc basic until something of LuxAsm is working -- ie. by adding actual components of the LuxAsm compiler/ide into the library as it is built.

Also searching for public domain assembly snippets and adding them to the library would help... plus I could contribute my own (fairly adhoc) library, there are some nice optimised data structure searchs in there... but before we start thinking of a library we have to start planning what syntax is suitable for LuxAsm, ie. how close to RosAsm should that syntax be... I am thinking about some subtle extensions to the macro system, conditional assembly and structure support needs adding.

As for your last couple of paragraphs... to cruel; to cruel <evil grin> :-)

C
2004-02-04

How would LuxAsm be different from a customized front end on Eclipse?

> How would LuxAsm be different from a customized front end on Eclipse?

Right, I've not used Eclipse so I'm going by their website information here...looking at that then, yes, there's certainly a kind of "similarity of purpose" on the modular IDE front...in fact, it's nice to know that one of my usual "mad ideas" - as I was actually unaware of Eclipse - is already shown to be a good idea that works...

First, though, Eclipse plug-ins are written in Java and XML...to switch to this would be a radical departure from the original concepts, such as LuxAsm being written in LuxAsm itself and being completely assembly based...this would change the nature of the project completely and, therefore, simply I'm not sure if it's what everyone here signed up for...

Second, LuxAsm is - to sound a bit like Rene here - "specific"...the grounding in a similar "modular" architecture to Eclipse isn't the purpose of the project but simply a case of creating good, solid, flexible foundations on which to base things...

For example, the LuxAsm components don't merely "integrate" with the IDE but integrate _with each other_...as an example of what I mean, there was an idea I had that there would be a "project tree" module, responsible for presenting the file hierarchy and controlling the module, which actually is really just a "front-end" onto MAKE...now, the main actual LuxAsm components are designed to work together...and for something like MAKE, the "project tree" module can actually communicate directly with the "LuxAsm assembler" module and ask it to parse the files in the project tree, looking for "include" statements so that it can generate a reliable list of "dependencies" and then these can be added to the project tree view...so, you would add a file to your project and the "project tree" module would then call on the "assembler" module to quickly parse the file and return its dependencies, which are then automatically added to the project tree view...to the user, they simply drag and drog a file into the project tree and - "as if by magic" - the include files and auto-dependencies are automatically attached onto the file (_reliable_ information too, as it is the _assembler_ which has located this information so what it says is accurate because it is the actual tool that will be assembling these files...rather than having the "prject tree" module attempt its own quick parsing for "include" statements...which would either be a complete duplication of the assembler's parsing code to be accurate or would only do some "text search" for the word "include" and could risk being inaccurate as, say, though is contrived as it would be easy to avoid in practice, the word "include" is actually inside a comment and isn't a real include...or, as perhaps a better example, with some "IncludeOnce" functionality (HLA has this, for example), it can _know_ accurately that the include file was already included once before)...

Another example is that the text editor could communicate with the assembler also in order to also ask it to only parse the file, returning information about the source code that can be used by the text editor to provide _fine-grained_ and _accurate_ syntax-highlighting...most syntax highlighters tend to simply parse a file looking for keywords and operators and such...this, again, either duplicates the assembler's parser completely to be accurate or risks incorrectly parsing the file and colouring things the wrong colour...

Further, simply glancing over a source file means that most of these syntax highlighters aren't fine-grained enough...for instance, all "user identifiers" are a single colour...but if we're getting accurate information from the assembler's parser itself then we can colour much more precise categories like "function", "macro", "data type", "class", "instance", "data variable", etc. and can colour these separately...this is a level of functionality not usually found elsewhere because they don't use such _deep_ integration between components...

The ultimate intention with LuxAsm is just such "deep integration"...the "modular" approach is NOT really to separate these things functionally at all - we want them not only integrated but I'd say "deeply integrated" - but is there to provide a flexible framework for development and extension...in other words, when they are "modules", I can be working on one, Daniel on another, C on another, Frank refining the text editor to handle integration with C's new module, etc....

We're not "competing" with Eclipse; It's a general-purpose tool integration suite thingy...that is not our primary intention at all...we are going for, in spirit, something like Rene's RosAsm in so far as a "deeply integrated" suite of tools (actually, more so than RosAsm, I'd say) for, _specifically_, development of assembly language applications on Linux / X-Windows...

The use of a "framework" is a _developmental_ thing...it's a good solid set of _foundations_ to work off that is automatically thinking in terms of "piecemeal" / "future expansion" / "ready for version 2" / etc....it also opens up the possibility to, yes, add third-party tools and create "filters" for accessing NASM...and, likely, at first, using NASM and MAKE and other third-party tools is a way to get things up and running fast (just "borrowing" NASM until LuxAsm's own assembler is coded :)...if, indeed, we do develop a NASM "filter" simply to act as a "placeholder" for the LuxAsm assembler (or MAKE for our own "project tree" stuff or GDB for our own debugger and so forth) then we might as well keep those lying around for users to use, if they really want...but they probably _won't_ want to in general because the LuxAsm components will be "deeply integrated" to bring things like the two examples I gave above: accurate drag and drop auto-dependency, accurate fine-grained syntax highlighting...

This was one thing that Rene was correct in thinking towards but I don't feel properly exploited in his RosAsm sufficiently (if I'm harsh, I could be pressed to say "at all" ;)...when tools are very "deeply integrated", there are levels of functionality and features possible that simply plugging an assembler into some generic IDE _can't_ match...

On this point (and probably _only_ this point ;), we are supportive of Rene's "specific" concept...so, indeed, we're NOT some "generic" Java plug-in passing XML to a general-purpose IDE...that stuff is, of course, utterly admirable and has its purpose...but the intention here is "specific" and "deeply integrated" so that the features provided to the programmer using LuxAsm are literally "made to measure"...amongst the nonsense Rene spouts, this was a diamond in the mud...

It's a decision some don't want to take, as we can hear from all the talk of "portability" and Java and XML; But, for example, when you choose to program in ASM, you have implicitly made just such a "specific" decision: "I am _sacrificing_ portability to other CPUs in order to be able to _specifically_ tailor my code to exploit this CPU to its maximum capabilities"...

There is, of course, NOTHING wrong with "portability" in the slightest (I'll, indeed, be using some of the work on X-Windows here to help Randy introduce some more "portability" to his HLA package :)...but what we're talking about is _making a decision_...a firm decision...indeed, imagine me banging my fist on the table as I say it: "this program is for Linux...I don't care about Sun Sparcs, I don't want to do this for Windows"...and once you've made that firm decision, many things are, indeed, _extraneous_ and _unnecessary_...do we need to be "portable" to a washing machine? Nope...do we need to use a "portability" library here? Nope...introducing these things, therefore, will add a _redundancy_ to the program...it's jumping through "portability hoops" to gain flexibility to work on an iMac but we actually have no intention of being on that platform so going through big-endian -> little-endian -> big-endian translations would be a pure waste of time for our program...making the firm decision - as, implicitly, the choice of using ASM is already - is completely 100% a "trade-off"...but the interesting thing here is that we're making that trade-off in favour of performance as far as possible, not the usual "portability is an unquestionable god" non-decision...

If only Rene phrased it that well, eh? People might actually listen to him...in this regard - although, it is _doing again_, not "porting" - LuxAsm was and is "descended" from RosAsm...the way I like to phrase this is: "we're doing what Rene should have done in the first place"...

So, how is it different from writing some portable plug-ins for Eclipse? This, I'm sure, will be an unsatisfactory answer to many but the difference is _attitude_, so to speak...Rene might call it "philosophy" but I find that slightly pretenious, to be honest...

It might seem odd - Rene doesn't understand it - to base "specific" and "deeply integrated" on top of "modular"...but, well, this is a _practical_ thing mostly...development will be very flexible under such a system...but, also, there is still "specific" thinking behind this...X-Windows itself is client / server, ELF has dynamic linking, GUIs are event-driven, you can "mix and match" your toolkits and window managers, etc....so, we are _matching our environment_ as it happens to be and that is "specific"...yet, unlike Rene, it's still perfectly loose for the user to _choose_ "specific" or not, as they need...Rene never quite understood this but firm decisions don't require fascist police states to enforce them...the correctness of your decision is its own enforcer...

That's a weird answer, isn't it? But, strangely, this is the answer...it just seems odd because, usually, people make their decisions in the opposite direction: "make it portable", "don't tie it down", etc....but if you _can_ or _want_ to tie it down then you're choosing this specifically (e.g. "I want to be entirely 'ethical' and 'open-source' that my efforts are directed soley at Linux and UNIX", as LuxAsm itself is choosing to do...but, over on Win32, someone might choose "90+% of home users are PCs running Windows...that's sufficient market for what I want...let me tailor this program, therefore, specifically to that market and cater directly to it", as many computer games and things also choose...to say "okay, this is an X-box game" and then code it for the X-box specifically...yes, of course, you could be "generic" instead..."portable" source code...but this carries an implicit _sacrifice_ to make it work...neither decision - despite a lot of hype about "portability" or, conversely, Rene insisting that nothing should ever be "generic" at all - is actually "right" automatically...what is "correct" depends entirely on the application and its needs...

And the fundamental concept here is - in a way many things don't do, mandating XML this or Java that - that the decision is _left open_...because, truthfully, some academic in some "ivory tower" dictating "never use GOTO!", "assembly is dead!", "all applications should be in Java and XML to be portable!", etc. is NOT qualified to make these decisions...they are not, so to speak, working at the coalface...they should, therefore, be _left open_ to the developer to choose...of course, one decision _has_ been chosen with LuxAsm already: it's an assembler...but that's not a philosophical thing in that case, it's just that we're all ASM coders and want to write and promote ASM on Linux and X-Windows...

"Specifically generic" or "generically specific", take your pick...I already know that Rene nor our "ivory tower" academic would make this decision because they'd choose their "everything should be specific!" or "everything should be generic!" extreme opinions...but I would say, if you're such an "extremeist" - whatever the topic - you're simply wrong...some situation will NOT be appropriate to your fixed decision...

Rene won't recognise it but this the non-insane version of what he was basically trying to express and achieve with RosAsm...LuxAsm, as I say, is doing what Rene wanted to do but doing it _properly_ ;)

[quote]
I was just browsing through the mail archive and I wondered if there is any plan of how to go about this project?
[/quote]

It would seem obvious (at least to me) that it would be:
Syntactical Planning -> Editor Design -> Editor Creation -> Assembler Creation -> Debugger/Disassembler/ect. Creation

Something that I'm trying to understand is what syntax is going to be used. It going to keep with RosAsm syntax, improve it, or create another syntax. If you improve RosAsm syntax, I think one should be able to look at a stretch of code and tell if it's RosAsm or LuxAsm code. RosAsm syntax was designed to work with RosAsm, so LuxAsm should (I assume) have its own syntax for LuxAsm. This sounds logical (at least to me), so correct me if I'm wrong.

[quote]
[quote]
I was just browsing through the mail archive and I wondered if there is any plan of how to go about this project?
[/quote]

It would seem obvious (at least to me) that it would be:
Syntactical Planning -> Editor Design -> Editor Creation -> Assembler Creation -> Debugger/Disassembler/ect. Creation
[/quote]

First is to implement the assembler (my task) while investigating
X and designing the (programme level) interface to the IDE system
(which we really should be getting proposals for by now -- guess
I will be doing all the coding myself :-)

So the plan is something like...
* Design assembler syntax.
* Write basic assembler (using Nasm).
* Design modular IDE API interface.
* Write standard macro library.
* Write IDE core and editor subsystems.
(There are likely to be many components.)
* Convert base assembler source from Nasm.
* Integrate assembler into Luxasm IDE.
* Write support tools (debugger, profiler, ...).
Most of these tasks can be done in parallel, the
first is already complete and the second is making
good progress.

[quote]
Something that I'm trying to understand is what syntax is going to be used. It going to keep with RosAsm syntax, improve it, or create another syntax. If you improve RosAsm syntax, I think one should be able to look at a stretch of code and tell if it's RosAsm or LuxAsm code. RosAsm syntax was designed to work with RosAsm, so LuxAsm should (I assume) have its own syntax for LuxAsm. This sounds logical (at least to me), so correct me if I'm wrong.
[/quote]

Though the original plan was to use an extension of RosAsm's
syntax, that plan came up against some problems. (Not to
mention the fact that RosAsm's syntax is to assembler what
Perl is to HLL's -- something akin to line noise.) As a result
the current design of Luxasm's syntax is based more on an
extended version of Nasm's syntax, with a few deviations. I
have been posting examples to alt.lang.asm recently using
this syntax (plus macros). Also you can download the Nasm
version of the Luxasm assembler from either the sf.net cvs
or by clicking on 'download' at http://luxasm.sf.net . Though
incomplete it will parse the basic syntax, and contains a
copy of the BNF definition of the syntax in the 'parse.asm'
module.

It is probably better to post to the luxasm-devel mailing list
this forum seems pretty dead at the moment, so you are
likely to get a faster responce though the mailing list (or
by posting on alt.lang.asm).

C
2004-07-05

[quote]
It is probably better to post to the luxasm-devel mailing list this forum seems pretty dead at the moment, so you are likely to get a faster responce though the mailing list (or by posting on alt.lang.asm).
[/quote]

I'd post on the LuxAsm-devel mailing list, but it's read-only for me.