«

Hello,

I have been promising an object orientated ASM IDE for a while now.
Trying to make the best of what is already here, I have made a compiler,
that will parse XML code and output ASM files.

The program still needs an internet interface (will do that tommorow),
but here is an example of what the code looks like, to wet your appetite:

<?xml version="1.0"?>
<code
xml:base="http://my.webspace.com/"
xmlnslink="http://www.w3.org/1999/xlink">
<Default xmlns:href="Default.xml"></Default>
<RegisterA xmlns:href="AX.xml">
<RegisterB xmlns:href="BX.xml">
mov ax,00FFh
mov bx,0FF0h
cmp ax,bx
mov cx,ax
</RegisterB>
</RegisterA>
mov ax,cx
</code>

The point is, that since the compiler is W3C XML and XLink compilant,
you can now use whichever XML editor (IDE) to work with your ASM code
(colorfull, named XML tags tend to be lighter on the eyes, when you are
looking for something in the code). The compiler works like this example:

<Whatever xmlns:href="AX.xml">
...
</Whatever>

Relates to this file (AX.xml):

<?xml version="1.0"?>
<Compiler>
<Begin>
push ax<br>
mov ax,0000h
</Begin>
<End>
pop ax
</End>
</Compiler>

To produce this code:

push ax
mov ax,0000h
...
pop ax

And while this example may seem silly, using this and an XML editor, it
becomes much more unlikely for you to end up with an out-of sequence
stack and any of the terrible consequences this usually brings. Not to
mention the segments can be labeled, making the program easier to read.

The XLink-ed XML of course, can be made to point to any ASM code you
choose and best of all, they do not need to be on the machine your are
compiling on, but anywhere on the internet. In this way you can define a
simplified language with these XML objects, then put them on a web
server and you never have to worry about them again, you can create
programs that you share with your friends / coworkers over the internet
and you only have to send them your XML program (which I might add is
also doomed to be much more understanable than the compiled ASM to them)
and if they wish to compile it, the components needed will be downloaded
automatically durring the compilation procedure.

The other good thing about this is that, if there ever will be large
compatible databases of these XML objects online, porting an ASM program
written in this XML language (to another ASM form or to diffirent
hardware / software) will be simply a matter of changing the XML:base
link (xml:base="http://my.webspace.com/") to point to another location,
compile and viola, the code is ported.

I might improove the language used in case it turns out to be too
loosely compilant to W3C standards or if there are other practical
aspects of the XML standard that can be used, but it will be
backwards-compatible and I will avoid fixed high-level features such as
the many in HLA. I have no intention of reinventing hot water.

P.S.: You will notice that the XML compiler can also be used to compile
anything else made up of text, not only ASM programs.

Coming soon! Like... tommorow! Now I got to go to bed. =P

--
Model: INFJ
Primary function: Coprocessor
Secondary function: Cluster commander

"None felt feline, so I discounted copycat syndrome..."
-- Ghost Song

On Fri, 04 Mar 2005 00:26:14 +0100, Jure Sah wrote:

[snip]

I'd have to say that it is a very creative assembler you are creating...
Though I do ask, what does XML give me over plain text?

Vi and Emacs, very awesome general purpose text editors, both offer syntax
highlighting, and plenty of assemblers know how to include files.

Though this looks like it could work, I'd have to see the program itself
though to make a decision.

PS. Looks kinda like that Unified model Beth was talking about

Percival

"Jure Sah" <> wrote in message
news:...
> Hello,
>
> I have been promising an object orientated ASM IDE for a while now.
> Trying to make the best of what is already here, I have made a compiler,
> that will parse XML code and output ASM files.
....
>
> And while this example may seem silly, using this and an XML editor, it
> becomes much more unlikely for you to end up with an out-of sequence
> stack and any of the terrible consequences this usually brings. Not to
> mention the segments can be labeled, making the program easier to read.

It really sounds like you're trying to create an XML version of the
fabled "BethTools" system (seach Google for details).

>
> The XLink-ed XML of course, can be made to point to any ASM code you
> choose and best of all, they do not need to be on the machine your are
> compiling on, but anywhere on the internet. In this way you can define a
> simplified language with these XML objects, then put them on a web
> server and you never have to worry about them again, you can create
> programs that you share with your friends / coworkers over the internet
> and you only have to send them your XML program (which I might add is
> also doomed to be much more understanable than the compiled ASM to them)
> and if they wish to compile it, the components needed will be downloaded
> automatically durring the compilation procedure.

And what's the point?

>
> The other good thing about this is that, if there ever will be large
> compatible databases of these XML objects online, porting an ASM program
> written in this XML language (to another ASM form or to diffirent
> hardware / software) will be simply a matter of changing the XML:base
> link (xml:base="http://my.webspace.com/") to point to another location,
> compile and viola, the code is ported.

Well, if you're going to give up machine dependence, which it sure
seems to me like you're doing this, then why not just use a HLL?

>
> I might improove the language used in case it turns out to be too
> loosely compilant to W3C standards or if there are other practical
> aspects of the XML standard that can be used, but it will be
> backwards-compatible and I will avoid fixed high-level features such as
> the many in HLA. I have no intention of reinventing hot water.
>
> P.S.: You will notice that the XML compiler can also be used to compile
> anything else made up of text, not only ASM programs.
>
> Coming soon! Like... tommorow! Now I got to go to bed. =P

I wish you all the luck in the world, but have you answered a
couple of important questions:

1. "Who is the audience for this product?"
2. "What is the purpose of this product?"
3. "Why would someone use this product over other assemblers (or HLLs)?"

HLA, for example, was designed to support beginning assembly
language programmers. That completely answers the three questions above.
What benefits are you proposing? Being able to edit your assembly programs
with an XML editor isn't a great turn-on to most programmers around here.
Indeed, speaking from experience, I can pretty much assure you that
there are only a tiny fraction of existing assembly programmers who
would be willing to switch to your system, once it's complete. That
leaves beginners as the only large market for such a system. What
benefits does this offer to those wanting to learn assembly? Perhaps
those who already know XML? (I don't know...). Of course, if
you're like Herbert and you just want to create an assembler for
yourself, have at it.
Cheers,
Randy Hyde

Randall Hyde wrote:
>>And while this example may seem silly, using this and an XML editor, it
>>becomes much more unlikely for you to end up with an out-of sequence
>>stack and any of the terrible consequences this usually brings. Not to
>>mention the segments can be labeled, making the program easier to read.
>
> It really sounds like you're trying to create an XML version of the
> fabled "BethTools" system (seach Google for details).

Google does not give any matches on that string.

>>The XLink-ed XML of course, can be made to point to any ASM code you
>>choose and best of all, they do not need to be on the machine your are
>>compiling on, but anywhere on the internet. In this way you can define a
>>simplified language with these XML objects, then put them on a web
>>server and you never have to worry about them again, you can create
>>programs that you share with your friends / coworkers over the internet
>>and you only have to send them your XML program (which I might add is
>>also doomed to be much more understanable than the compiled ASM to them)
>>and if they wish to compile it, the components needed will be downloaded
>>automatically durring the compilation procedure.
>
> And what's the point?

That it is more readable, easier to organize and change, prevent
doubling-up of work already done for other software and simpler to
costumize to serve another purpose.

>>The other good thing about this is that, if there ever will be large
>>compatible databases of these XML objects online, porting an ASM program
>> written in this XML language (to another ASM form or to diffirent
>>hardware / software) will be simply a matter of changing the XML:base
>>link (xml:base="http://my.webspace.com/") to point to another location,
>>compile and viola, the code is ported.
>
> Well, if you're going to give up machine dependence, which it sure
> seems to me like you're doing this, then why not just use a HLL?

XMLc is not exclusive to use, you can quite simply use XMLc to compile
programs which are then to be processed trough your HLL processor. XMLc
is programming-language independent and still maintains it's full list
of potential advantages.

> I wish you all the luck in the world, but have you answered a
> couple of important questions:
>
> 1. "Who is the audience for this product?"

Perhaps, as you later mention, also myself, but generaly it could be either:
1. Any ASM programmer who wishes to keep his code readable and reusable.
2. Anyone who does not have enough experience to be able to smoothly
read ASM code and can utilize a handy graphical representation of the code.
3. Any group of people working togather on one ASM program.

> 2. "What is the purpose of this product?"

To provide a commonpoint for many diffirent programming languages, thus
create an universal devolopment environment of tools hand for the
devolopers and to make it up to globally accepted standards. For
example: Provide the advantages of using XML editors to ASM programmers.

> 3. "Why would someone use this product over other assemblers (or HLLs)?"

Pointless question, I think those who are used to other assemblers or
HLLs and find XMLc usable will be in fact using both (since XMLc
produces code, not binaries). But I suppose the prospect of being
object-orientated, internet-level portable and compilant to world
standars, without making sacrafices on the effectivness of the code
itself has got to attract some attention.

> HLA, for example, was designed to support beginning assembly
> language programmers. That completely answers the three questions above.
> What benefits are you proposing? Being able to edit your assembly programs
> with an XML editor isn't a great turn-on to most programmers around here.

And you speak for all of them?

> Indeed, speaking from experience, I can pretty much assure you that
> there are only a tiny fraction of existing assembly programmers who
> would be willing to switch to your system, once it's complete. That
> leaves beginners as the only large market for such a system. What
> benefits does this offer to those wanting to learn assembly? Perhaps
> those who already know XML? (I don't know...). Of course, if
> you're like Herbert and you just want to create an assembler for
> yourself, have at it.

The main idea behind this project was a while ago, when a friend working
in the area of Artificial Inteligence, brought to my attention XML, the
language where meaning can be described (at the time I was working on
poly-dimensional context-based search spheres) in a simple hierarchical
format, where the language is dnyamic and everything is refferenced to
defenition maps that the XML is linked to over the internet.

The point of that refference was that if everything is somewhere on the
internet, and compilant to world standards, it is easy to use and does
not have to be re-made. XML is also a language that enables you to put
various kinds of information that various diffirent programs will be
using, contextfully, in the same XML file. Being XML compilant you gain
a lot and being able to utilize a language on top of another that gives
you standard-compilance also means that the information stored within
your code is:
1. Manipulatable with any XML compilant editor
2. Readable by any XML compilant reader (which may include several
applications not interested in the ASM code within)

So being XML compilant alone has a point.

I suppose many more people have been taught XML than are willing to try
ASM. XML has a future, raw ASM (they say) does not. People will use Java
and simmilar programing languages because they share these
characteristics of XML, but Java is a slow interpreted language. XMLc
gives you all the advantages of being able to utilize modern programming
language standards, it's language has and will continue to have plenty
of usable editors worldwide and at the same time, leaves you with
working, highly efficient and fully costumizable low-level code.

I will, as far as I'm concerned, utilize the XMLc and create my objects
and share them on the internet, perhaps once there are more of them,
people who are new to ASM may seek to utilize those instead of going for
raw ASM rightaway. But I suppose, as W3C says about XML, that it is a
good standard that hopefully everybody will embrace as a part of good
working praxis, and take that as a recomendation.

But I will not force it on you, it is a usable tool and a good idea if
you ask me, and it will be freeware.

--
Model: INFJ
Primary function: Coprocessor
Secondary function: Cluster commander

"None felt feline, so I discounted copycat syndrome..."
-- Ghost Song

Percival wrote:
> I'd have to say that it is a very creative assembler you are creating...
> Though I do ask, what does XML give me over plain text?
>
> Vi and Emacs, very awesome general purpose text editors, both offer syntax
> highlighting, and plenty of assemblers know how to include files.

<kidding> More portability in that case (Windows . </kidding>

Well but generally:
1. XML allows web-based refferences
2. XML is more globally-accepted as a type simmilar to to
object-orientated text, which leaves you with the poitential of using
graphical-representation tools to display a finnished ASM program,
allowing you to more easily explain the structure of your program to
people who are not yet fammiliar with your code and require to be. I
wonder if vi or emacs can do that.

> Though this looks like it could work, I'd have to see the program itself
> though to make a decision.

Noteworthily, I've made the devolopment version in MS VB, so if you
can't run that, you're gonna have to wait until a final version when I
translate it to C (or whatever prooves to be most suitable anyway).

> PS. Looks kinda like that Unified model Beth was talking about

Is that model world standard compilant?

--
Model: INFJ
Primary function: Coprocessor
Secondary function: Cluster commander

"None felt feline, so I discounted copycat syndrome..."
-- Ghost Song

"Jure Sah" <> wrote in message
news:gcXVd.9827$...
> Randall Hyde wrote:
> >>And while this example may seem silly, using this and an XML editor, it
> >>becomes much more unlikely for you to end up with an out-of sequence
> >>stack and any of the terrible consequences this usually brings. Not to
> >>mention the segments can be labeled, making the program easier to read.
> >
> > It really sounds like you're trying to create an XML version of the
> > fabled "BethTools" system (seach Google for details).
>
> Google does not give any matches on that string.

Try a Google search on this very newsgroup.

> > And what's the point?
>
> That it is more readable, easier to organize and change, prevent
> doubling-up of work already done for other software and simpler to
> costumize to serve another purpose.

Thus far, the examples really haven't demonstrated this.
Sure, I know what XML promises, but until you've got
a lot of code working in your system, it's hard to predict
what the impact will be.

As for preventing duplication of effort, I'm afraid you have
far too much faith in your fellow programmer's willingness to
switch from the way they now do things. All that will happen
is that you add yet another way to do things to the mix.
That's not bad, mind you, but...

>
> > I wish you all the luck in the world, but have you answered a
> > couple of important questions:
> >
> > 1. "Who is the audience for this product?"
>
> Perhaps, as you later mention, also myself, but generaly it could be
either:
> 1. Any ASM programmer who wishes to keep his code readable and reusable.

There are *other* solutions, too.
Most of them don't involve a familiarity with XML as a prerequisite.
Considering the number of people around here who don't even know C
as an indication (and who refuse to learn it), I think you'll find you have
an uphill battle. Sure, when the system is fully functional, you'll be able
to claim that knowing XML is not a prereq, but I doubt many assembly
programmers would believe this (it's their nature to want to know how
things work "under the covers").

> 2. Anyone who does not have enough experience to be able to smoothly
> read ASM code and can utilize a handy graphical representation of the
code.

Again, the proof is in the final product.
It's a nice idea, but we shall see.
A better product would be something like ASMFlow that takes an
existing assembly program and produces the XML code that will
do what you want, without forcing its initial use on the programmer.

> 3. Any group of people working togather on one ASM program.

We can do that today, using standard tools.

>
> > 2. "What is the purpose of this product?"
>
> To provide a commonpoint for many diffirent programming languages, thus
> create an universal devolopment environment of tools hand for the
> devolopers and to make it up to globally accepted standards. For
> example: Provide the advantages of using XML editors to ASM programmers.

Okay, but now you've got to convince everyone that this is a good idea.
I daresay that most assembly programmers wouldn't have a clue why
using an XML editor to edit assembly is a good idea (I sure don't).

>
> > 3. "Why would someone use this product over other assemblers (or
HLLs)?"
>
> Pointless question, I think those who are used to other assemblers or
> HLLs and find XMLc usable will be in fact using both (since XMLc
> produces code, not binaries). But I suppose the prospect of being
> object-orientated, internet-level portable and compilant to world
> standars, without making sacrafices on the effectivness of the code
> itself has got to attract some attention.

But after the initial attention, who will use it?

>
> > HLA, for example, was designed to support beginning assembly
> > language programmers. That completely answers the three questions above.
> > What benefits are you proposing? Being able to edit your assembly
programs
> > with an XML editor isn't a great turn-on to most programmers around
here.
>
> And you speak for all of them?

Based on my experiences with the programmers around here,
I probably speak of (rather than 'for') most of them, yes.

> The point of that refference was that if everything is somewhere on the
> internet, and compilant to world standards, it is easy to use and does
> not have to be re-made. XML is also a language that enables you to put
> various kinds of information that various diffirent programs will be
> using, contextfully, in the same XML file. Being XML compilant you gain
> a lot and being able to utilize a language on top of another that gives
> you standard-compilance also means that the information stored within
> your code is:
> 1. Manipulatable with any XML compilant editor
> 2. Readable by any XML compilant reader (which may include several
> applications not interested in the ASM code within)
>
> So being XML compilant alone has a point.

Sure.
But will other people accept that point.
That's all I'm asking.
Cheers,
Randy HYde

Percival wrote:
> PS. Looks kinda like that Unified model Beth was talking about

Well, if it _looks_ like that, then I assure you "appearances are
deceptive" because what Jure is doing here seems to be different...kind
of...there is a similarity in catering for "object-orientated assembly" BUT
that's about as far as it goes, I think, because the "approaches" being
taken appear quite dissimilar to me...Jure is using that whole XML thing
and the subject line says "pre-assembler" (what Rene would call a
"pre-parser" and about using XML editors, so the approach seems very
different...

In essence, we're just going for "hierarchical labels" with the
"block-structured" mechanism...and we're only really adding "{}" to
otherwise ordinary NASM-like assembly code...this XML thing doesn't appear
to be quite as "simplistic" as that from the examples...

Beth

Jure Sah wrote:
> 2. XML is more globally-accepted as a type simmilar to to
> object-orientated text, which leaves you with the poitential of using
> graphical-representation tools to display a finnished ASM program,
> allowing you to more easily explain the structure of your program to
> people who are not yet fammiliar with your code and require to be. I
> wonder if vi or emacs can do that.

Graphs!!! Of course!! Graphs!!! Why didn't I think of that? Graphical
structural representations...thanks for the suggestion! ...

[ snip ]
> > PS. Looks kinda like that Unified model Beth was talking about
>
> Is that model world standard compilant?

<response>
<kidding>
No, it doesn't suffer from being "ruined by committee" in being forced to
be rooted to 1960s technologies for "backwards compatibility" with ENIAC
and so forth
<sarcasm>
XML, you say? Oh, yeah...that's those plain text files littered with
strange punctuation characters, isn't it? Ah, yes...ASCII plain text that
has, for once, a bit of "self-discipline" in its structural
presentation...very "high technology"...they'll be inventing ".ini files"
or something next...
</sarcasm>
</kidding>
<signature>
Beth
</signature>
</response>

On Fri, 04 Mar 2005 14:04:58 +0000, Randall Hyde wrote:

> Again, the proof is in the final product.
> It's a nice idea, but we shall see.
> A better product would be something like ASMFlow that takes an
> existing assembly program and produces the XML code that will
> do what you want, without forcing its initial use on the programmer.

Hmm, sorta reminds me of web and tangle and Knuth's "Literate Programming"
idea. I never tried ASMFlow...

Perhaps the xmlweb program will translate xml to some sort of graphic? And
tangle will be the extractor of the assembly data so you have 3 versions
of the source, 1 you wrote, 1 that is a picture painted by XML, and 1 is
the one that will be compiled.

Meh, literate programming in assembly... Lol. It could work, but I have
yet to see it. (Other than abundance of comments, but thats not exactly
the same)

Percival

Jure Sah wrote:

[lots of stuff about an XML-based ASM with graphical, networking, and
machine-independence characteristics]

>From my understanding, there are already tools that let you design
software by drawing a flowchart (and here I thought flowcharts became
obsolete along with punchcards) and generating the appropriate source
for your chosen language. Aren't these called CASE tools? If you are
designing for platform-indepedence and using CASE tools, then you are
working at a high-abstraction level -- assembly language has no place
in this environment. Assembly hugs the machine-dependent, low-level,
non-abstraction style side of the programming scale so it would be a
very poor choice for the output of a Flowchart Development Environment
based on networking and platform-independence. Also, where on this
Earth (outside of Redmond, Washington) are you going to find
programmers who willingly severly criple their applications by making
them dependent on code only available on the internet?

Nathan.