Re: Ann: Luxasm 00.01.00 (2004-04-08)

From: C (blackmarlin_at_asean-mail.com)
Date: 04/15/04

  • Next message: Bx.C: "Re: I feel so deeply hurt." 
    Date: 15 Apr 2004 11:06:12 -0700

    Frank Kotler <fbkotler@comcast.net> wrote in message news:<407C0600.6010203@comcast.net>...
    > C wrote:
    >
    > > Frank Kotler <fbkotler@comcast.net> wrote in message news:<40770E15.4030307@comcast.net>...
    > >
    > >>C wrote:
    > >>
    > >>>http://luxasm.sourceforge.net/source/luxasm.all.20040408.tar.bz2
    > >>
    > >>"It doesn't do anything when I click on it!"
    > >>
    > >>... yeah, I know it isn't intended to... just pointing out that we're
    > >>going to need a *completely* different interface, eventually...
    > >
    > > It should not be too difficult to attach a different interface (IDE)
    > > due to the modular design, either by running it using sys_exec or
    > > by integrating the relevant modules into the IDE itself.
    >
    > If this still-fairly-nebulous IDE is going to do syntax highlighting,
    > we'll probably want to borrow your code to find out what's what.

    Yes, the idea with some of this code is to merge with the IDE so
    concurrent compilation and highlightling may be done simultanously
    (as much of the code to do this would be the same)... but this is
    some way down the line, firstly I want to get Luxasm able to compile
    itself before the IDE is handled, ideally by someone else as I am
    only familiar with Motif and I guess we want to be using some other
    toolkit, which is best is something I cannot decide.

    > Whether we "keep" these results to use for "concurrent assembly"
    > (you like that one, Beth?) is another question.

    We should be able to achieve this.

    > I've been messing with "system() without libc", and I think I've
    > got something working - currently I can call mcedit, nasm, and
    > ld with command lines to do "hello.asm" (this is probably no news
    > to experienced Linux programmers, but it's all new to me!)

    Good, I would like to see your results.

    > - needs an interface... But I think we're better off "integrating"
    > the actual "LuxAsm assembler". Perhaps "later" is better - after
    > it can assemble itself as a command line tool.(?)

    Yes, I think that option will save time in the long run.

    [snip]

    > If I may combine replies...
    >
    > C wrote:
    > > The Half a Wanna bee <shakainzulu@hotmail.com> wrote in message
    > news:<4075eb3d$1@news.broadpark.no>...
    > >
    > >>C wrote:
    > >>
    > >>Hello C. I have downloaded and unpacked it now. Will start
    > >>reading now. I think I begin with Philos :-) see you.
    > >
    > >
    > > Nice, please ignore all the typos and spelling erroring in that
    > > file -- they then to creap in when I am thinking as I am writing
    > > and then fail to proof read, as is always the case with incomplete
    > > documents.
    >
    > The request for URLs for "other assemblers" is noted.

    The main reason for this is that I could use a description of
    assemblers I do not use. This will allow Luxasm to avoid pit
    falls in other assemblers and maybe pickup some useful/unique
    features present in the most esotiric assemblers.

    > This is something that should be done via CVS. I think I understand
    > how to import something into the CVS repository, and I'll take a
    > crack at if no one else wants to,

    Would seem a good idea... I really have no idea about CVS so I
    am of little use there.

    > but I'm not sure what it should include. Do we want the
    > "_sass" directory in there?

    Probably not, (that assembler was designed and written years ago
    when I was just teaching myself how to use C/Bison/Flex as a
    result it not very good -- it is only present because I am
    grabbing a few algorithms from it to use in Luxasm).

    > Maybe the source code should go in a "nasmese/" directory, to
    > be translated to "native" syntax and moved to its permanent
    > location eventually?

    That seems a very good idea. At least for the "source" and
    "macro" directories. The "examples" and "library" directories
    could probably be included in the main source tree as with the
    "document" directory -- though that really does need a lot of
    cleaning up first.

    > In any case, "philos" needs to go up there.

    "philos" is really part of the documentation, my proposal being to
    split the documentation into five sections.
    1) Philosophy -- explaining what Luxasm looks the way it does,
    why it was written, comparing features of other assemblers, musings,
    etcetera (this section may be safely ignored).
    2) Basic assembler syntax, simply the basic syntax and directives
    of Luxasm needed to get a simple programme written -- this deals
    with the "pure assembly" mode of luxasm.
    3) The standard macro library usage notes for Luxasm.
    4) Advanced assembler syntax, covering the macro and other
    more complex assembly syntax features.
    5) Appendix, processor instructions (could nab this from NASM :-)

    In addition several tutorials needed to be written to cover the
    basics of Luxasm from a beginners persepective, plus how to use
    the macro library and advanced features. This should complement
    the documentation -- ie. while the documentation acts as a reference
    for finding specific details, the tutorial acts as a step by step
    guide of how to write the common collection of software in Luxasm.

    > I can help with authors and URLs - maybe touch up some of the
    > typos. Other developers might want to contribute something to it,
    > too

    Yes, I would find descriptions of unique/uncommon features in
    other assemblers quite useful at this stage -- though documenting
    the code would be a little more difficult at this stage giving that
    it is still in a state of flux, maybe when it can generate binaries
    it would be a good idea to get on with writing up the documentation.

    Now, though, a wish list for the macro library would be a useful
    as it will allow me to adjust the syntax should it prove insufficient
    to implement some macro deamed useful by others. Looking though the
    "macro" directory for the NASM macros as well as the "examples" and
    "library" should be helpful in understanding what can be achieved
    via macros. Maybe translating some of the NASM macros could be
    useful -- though Luxasm often achieves the results using a rather
    different macro syntax to NASM.

    Also test code / examples would be useful and should be possible
    now you all have some idea of the basic syntax. (The idea being
    to try and 'break' luxasm -- even bad code should at least
    generate understandable errors, not crash the compiler.)

    > - at least if we screw it up, it won't introduce mysterious
    > bugs into the code!

    :-)

    > (maybe other developers don't even *agree* with your philosophy)

    Quite probably, though I would be interested in where those
    hypothetical disagreements lay.

    > Any advice on just what the directory structure for the initial import
    > into CVS should be would be welcome. Much easier to get it right the
    > first time than to have to *** around with CVS changing it!

    My suggestion:

    Luxasm/ Root
      source/ Source code (luxasm)
      test/ Test bench / correctness tests
      library/ Macro library
      examples/ Example code snippets
      tutorial/ Tutorials (several)
      documents/ Documentations (1,2,3,4)
      binary/ Executables
      _nasm/source/ NASMese version
      _nasm/macros/ NASMese macros

    My problem is that I do not have tools to upload/download from CVS
    (lack of a home internet connection currenly due to NTL being
    stupid again) and the library computers are not configured for it.
     
    > (oh, while I'm thinking of it - comments about "maybe MIT license would
    > be better" on some files - best to decide that soon, too!)

    Currently I am shoving everything as GNU GPL 2.1 -- as this is one of
    the more restrictive licenses, things can be relaxed later, eg. the
    macro library should probably be BSD and the examples public domain.
    After all it is easier (via copyright law) to relax a restrictive
    license than to add greater restrictions to public domain. Comments?

    C
    2004-04-15

  • Next message: Bx.C: "Re: I feel so deeply hurt."