Re: Report from the LuxAsm mailing list for Betov

Rene wrote:
> Thanks, this is really funny. What will probably be even
> more funny should be the answer from Beth, as my guess is
> that she will not understand what real things are to be
> considered about this subject, and why and how, though it
> is, as usual, a big lie from Master Randall Hyde, there
> is effectively a real design problem, with this, for them,
> that is, in fact, the complete other way round.
>
> But, well... no need to explain... We have enough great
> experts, here, don't we? :)) :)) :))

Hey, hey...you should know the rule, Rene...never attempt to pre-empt my
replies before I make them...

Randy does NOT have a point when it comes to LuxAsm, anyway (paying
attention, NoDot? :)...because why on Earth do you think I came up with the
_DECOUPLED_ "modular architecture" to base this on?

LuxAsm modules _ARE_ fully "decoupled"...separate binary files...all links
between them dynamic and manually negotiated...designed with "scalability"
in mind that they "integrate" their _behaviour_ (not their independence) to
provide extra "tightly integrated" functionality...BUT, if the "link"
somehow fails - "file not found" - then they "fall back" to completely
_stand-alone_ "traditional" behaviour...

You will be able to use LuxAsm as a command-line tool - like any other -
for use with, for example, "makefiles" and so forth...if the editor crashes
then we do NOT have any of Rene's problems: Source is stored in _external
files_ (an editor crashing will not "lose" these files, exactly like any
other ordinary editor), for example...

Be clear: The IDE is merely a "compiler driver", similar to Randy's own
"HLA.EXE" (which calls "HLAPARSE.EXE", MASM / FASM, LINK / POLINK, etc. as
is appropriate) or GNU's GCC (which calls the "binutils" like GAS and LD in
the background :)...

So, you know, if this is a "problem" for us, then it's a problem for Randy
too because we're actually using the _exact same method_...the difference,
of course, is that LuxAsm's IDE provides this "compiler driver" method with
a "graphical front-end"...it's the GUI equivalent, so to speak...

[ In "command-line mode", you'll lose some of the "incremental" approach
but it'll still work in a "traditional" way...remember: If you "invalidate"
every line of a source file, then "incremental" _BECOMES_
"traditional"...traditional, if you like, is just the "special case" of
"incremental" where _all_ the lines have been changed...although, in fact,
to be more specific, "diff" will provide the actual changed source lines
from the file and then these are incrementally included...but this will be
"transparent" to users, who'll just see it as being very much like the
"traditional" way, except if only minor changes are made, then it all
proceeds very quickly (because we "only process the changes" in the
"incremental" approach)..."diff" is a standard UNIX tool but it's not
particularly complicated - compare two files and flag up which lines are
different - that the LuxAsm package will likely include its own (but, in
development, UNIX's "diff" can be used until we get one of our own
functioning, that can be "tailor-made" to, you know, fit into the whole
LuxAsm package :)... ]

Geez Louise, NoDot, you're creating "black propoganda" against yourself
here!! There is no such problem...indeed, LuxAsm's "scalability" approach
means that it does a damn sight _MORE_ than most programs - coupled or
decupled - do about such problems (which, anyway, shouldn't be a problem
because, of course, we're going to write an editor that _doesn't_ crash,
yes? ;) because it can operate in _both_ "modes"...

I already covered this with the "modular architecture" approach: LuxAsm
_WILL_ be exactly a decoupled "tool chain" like any other...the "trick",
though, is that it'll have a "GUI face" via the IDE and the "modules" are
able to "tightly integrate" (because, as has been noted, "shared libraries"
in Linux can also be made to directly execute...hence, to use Windows
terminology if that helps comprehension: If you run any of the "modules"
from the command-line, they act as command-line tools in the "traditional"
way (well, "traditional-ish", as "incremental" is still in effect...note:
If you've been paying attention closely, I always refer to "incremental"
and "type-time feedback" as _DIFFERENT THINGS_...the "feedback" in the
editor takes advantage of "incremental" to provide one of LuxAsm's "tightly
integrated" features...BUT "incremental" itself solely means: "Process
_only_ the changes, _once_"..."merge" changes into what's already there as
we go along...rather than constantly re-processing the same old lines over
and over again, every single time we build)...

Really, I've thought of this...and it was a _DELIBRATE_ design decision
because we, of course, were following RosAsm's "design" at first but I
stepped in to propose we do things _differently_ on this point, exactly to
support a plethora of different possibilities and ways of using the LuxAsm
"tool chain": _TOGETHER_ or _SEPARATELY_...the whole point of the idea, so
to speak, is that the tools are comfortable working in either
way...command-line or GUI...

Indeed, part of the idea is to _DECOUPLE_ even further: The tools just _do
their job_...the "user interface" is dealt with separately...this is the
entire point: It _WILL BE_ perfectly "decoupled" (more than some of the
"traditional" tools out there, in fact)...but that a "protocol" for
"inter-modular communication", so to speak, _IS_ part of the design itself
to allow the "modules" to directly "integrate" with each other (indeed,
it's "peer to peer" in design: The internet uses "peer to peer"
architecture _EXACTLY_ because it's the most robust model...the DoD chose
this design for their internal network exactly because of its robustness:
They wanted something with some chance of surviving - at least, for as long
as possible - an _ALL-OUT WORLD-WIDE NUCLEAR HOLOCAUST_...yes, it's _THAT_
"robust" a design...arguably, there is none better because the design
exactly counteracts all "single point of failure" problems...if Randy's ISP
is working then I can interact with it and send him an Email BUT should it
go down, then the entire internet does NOT go down with it..._THAT_ (as
well as better use of bandwidth and more direct communications) is the
entire point of a "peer to peer" design to design a network - or "tool
chain" in this instance - where "interdependency" is spread out as thinly
as possible (no single "module" should be so "crucial" that its failure
makes everything else fail: Yes, even the IDE)...and to design with the
possibility of a "peer" being as much alone, as surrounded by many peer
"friends"...it's capable of more stuff when "integrated" but all tools -
per UNIX philosophy and "peer to peer" design principles - function
"stand-alone" too)...

In fact, perhaps a different angle should be taken to explain this:

You know the UNIX tools? Stuff like "make", "diff", "as", "ld" and so
forth? Right, that is _EXACTLY_ the same basic format LuxAsm takes...now,
imagine those same tools but with "awareness" of each other: So, "as" can
parse a file, determine the "dependencies" and then supply this information
to "make"..."diff" can be used to determine which lines have been changed
since the last assemble and _only_ those lines are passed to (what is an
incremental version of) "as"...indeed, you _can_ do something similar-ish
to this, often, with the standard UNIX tools...though, they aren't really
"aware" of each other...instead, you're "piping" output from one into the
other...

BUT - if you read the "channels" page of the "design map" on the CVS,
NoDot - I've expanded on this by introducing the more flexible "channel"
system...a "channel", in this case, operates like a "pipe" does but is much
more flexible (you don't only "pipe" the output from one program to
another: The programs provide an array of "services" and you can "pipe" one
service to another service...that is, each program can take _MULTIPLE_
types of "input" and produce _MULTIPLE_ "outputs"...indeed, you know those
old manual telephone exchanges? Where there were many holes - one for each
phoneline - and then an operator would take a cable and could connect up
any two of the holes...the "pipe" mechanism only provides one "input" hole
and one "output" hole for each program...the "channel" expands on this by
allowing a program to have as many "input" and "output" holes as it
likes...each hole relates to a different "service" it provides...hook up to
the assembler's "assemble" service and then pass it source code and it'll
incrementally assemble that source...hook up to its "autodependency"
service and supply source code and, instead, it'll return the
"dependencies" of that source code for its output...hook up to its "syntax
highlighting" service and then the output it produces is information
suitable for the editor to "syntax highlight"...and so forth...if run via
the command-line, then it defaults to the "main service" in the
"traditional" way (as command-lines only comprehend "pipes", they don't
understand "channels")...but all of the "modules" themselves fully
understand "channel" communication and can locate each other and establish
"channels" between them to inter-communicate and "provide services" to each
other, where such services are available)...

On the contrary, there is no such problem in LuxAsm...LuxAsm is perhaps the
_ONLY_ design out there which inherently deals with these issues directly
to remain "decoupled" _without_ compromising "integration" (not that Rene
actually in any way makes use of "integration" in his tool, anyway...I
don't know why he bothered doing it that way, when he takes NO ADVANTAGE
out of the "integration" of assembler / linker / editor / resource compiler
altogether in one tool...you know, there is no real additional features
provided for this integration that an ordinary IDE cannot provide, with a
wholly "decoupled" architecture...a "lack of imagination" failure from Rene
there, methinks ;)...

If the editor crashes, then use Emacs or something instead to edit
it...this can still be sent to the tool chain in the "traditional"
way...what you lose is the "feedback", unfortunately (but, well, simply:
Emacs is "unaware" of this feature, so it can't take advantage of it)...but
it won't stop you carrying on...

Beth :)


.

Relevant Pages

  • Re: CPU recommendations?
    ... done well, classes, templates, and stronger typing can give you a better development environment (clearer and safer source code and at least as small and fast object code). ... C has so many design faults there is no space to list them here. ... inheritance will make an AVR run like an 8051, and multiple inheritance will turn your source code into Greek). ...
    (comp.arch.embedded)
  • LuxAsm questions
    ... "It" being "assembly apps" in Linux, not specifically LuxAsm ... and the design specs clearly state "Thou ... that our cabinet will fit together with existing cabinetry. ...
    (alt.lang.asm)
  • Re: Several, bring coffie
    ... Rene wrote: ... >> capable of designing and writing an assembler to make yours look ... It's not code...but there's 11MB of files from me on the LuxAsm ... the first code also needs the initial design and planning to get it ...
    (alt.lang.asm)
  • Re: Embedded processor (and OS, tools) selection for long-life product
    ... This is industrial safety monitoring equipment that also has to meet some minimal radiation rating. ... The biggest change is to add an ethernet port which could be satisfied by some kind of separate serial to ethernet adaptor design as long as all the IP were available. ... The original system design used the Intel i960 running the Intel iRMK kernel. ... You need to make sure that you get the source code for the entire design as well as the source code for the entire toolchain. ...
    (comp.arch.embedded)
  • Re: Interested about number crunching in Ada
    ... Honeywell Bull had to pay DEC for the source code of those close ... source code libraries. ... Honeywell Bull under contract to the US DOD in 77. ... The Design is a far cry from the true copyright, ...
    (comp.lang.ada)
Loading