Discussion:
ASM objects?
(too old to reply)
Jure Sah
2004-09-27 21:31:12 UTC
Permalink
Hello,

I am wondering if attempts to make ASM object-orientated and utilizing a
graphical interface to the coding process has ever been made?

If yes, screenshots please.

Otherwise, is it optimal to be using many 'subroutines' in an ASM
program, blocks of code designed for a specific purpose (such as for
example exporting a string to a file, etc), which the program then jumps
to and returns whenever there is a need for it, in your oppinion?


I am thinking of making a graphical interface where ASM code can be put
in objects where registers and the data pointers can be 'tied togather'
using a mouse, and the program then just makes the "MOV x,y"s and
"JMP"s, puts the code togather all in the right order, and passes the
finnished ASM code to whatever the user's assembler happens to be. The
second idea is then that these objects would be exportable as files and
shareable as well as groupable into bigger objects.

I'd need such an interface for my personal needs but I would of course
make it freeware.

Is this already done somewhere? Is your personal oppinion that such an
interface would be useless?

Looking forward to your response.
--
Primary function: Coprocessor
Secondary function: Cluster commander
John Found
2004-09-27 20:56:32 UTC
Permalink
Post by Jure Sah
Hello,
I am wondering if attempts to make ASM object-orientated and utilizing a
graphical interface to the coding process has ever been made?
If yes, screenshots please.
the project Fresh - http://fresh.flatassembler.net
It is atempt (pretty successful for now) for fully visual programming
RAD IDE for flat assembler (FASM).
There are screenshots of course, but you can download the whole package
- it is smaller than screenshots. ;) Download the latest work version.
The source is included - it is written fully in Fresh, so you can simply
open the project and press "compile"...

Regards
Jure Sah
2004-09-28 00:09:52 UTC
Permalink
Post by John Found
Post by Jure Sah
I am wondering if attempts to make ASM object-orientated and utilizing a
graphical interface to the coding process has ever been made?
If yes, screenshots please.
the project Fresh - http://fresh.flatassembler.net
It is atempt (pretty successful for now) for fully visual programming
RAD IDE for flat assembler (FASM).
There are screenshots of course, but you can download the whole package
- it is smaller than screenshots. ;) Download the latest work version.
The source is included - it is written fully in Fresh, so you can simply
open the project and press "compile"...
Actually... it seems I wasn't very clear with what I mean... With
"utilizing a graphical interface" I meant what I described below. That
the programmer writes objects and bundles them up into a program using a
graphical display and a mouse.

I've already dug into it... here's a screenshot of the program I am
working on in it's devolopment stages:
Loading Image...
The boxes represent code objects and the links between them will be
displayed as arrows when I work on it some more.

Anything like this out there? =P
--
Primary function: Coprocessor
Secondary function: Cluster commander
Randall Hyde
2004-09-27 21:51:42 UTC
Permalink
Post by Jure Sah
Hello,
I am wondering if attempts to make ASM object-orientated and utilizing a
graphical interface to the coding process has ever been made?
HLA and TASM have object-oriented capabilities.
But to my knowledge, no one has created anything like
Borland's OWL for these assemblers yet. All Win32 GUI
programming is done using the Win32 API. Under Linux,
it's calls to the GNOME API (or whatever window manager
you're using) which isn't OO IIRC.
Post by Jure Sah
If yes, screenshots please.
:-)
Post by Jure Sah
Otherwise, is it optimal to be using many 'subroutines' in an ASM
program, blocks of code designed for a specific purpose (such as for
example exporting a string to a file, etc), which the program then jumps
to and returns whenever there is a need for it, in your oppinion?
See the HLA Standard Library, for example.
http://webster.cs.ucr.edu
Post by Jure Sah
I am thinking of making a graphical interface where ASM code can be put
in objects where registers and the data pointers can be 'tied togather'
using a mouse, and the program then just makes the "MOV x,y"s and
"JMP"s, puts the code togather all in the right order, and passes the
finnished ASM code to whatever the user's assembler happens to be. The
second idea is then that these objects would be exportable as files and
shareable as well as groupable into bigger objects.
Good idea.
But why not make it portable between Win32 and Linux?
Now that would be really neat.
Post by Jure Sah
I'd need such an interface for my personal needs but I would of course
make it freeware.
Is this already done somewhere? Is your personal oppinion that such an
interface would be useless?
Looking forward to your response.
Someday, well in to the future, once I get HLA v2.0 operational,
my goal is to begin work on a portable GUI library that allows one
to write GUI apps that recompile under Linux, Win32, BSD, and
other x86 OSes (GNOME or Win32 based). Maybe even BeOS.
Obviously, I have an interest in this. :-) But I have other priorities
right now.
Cheers,
Randy Hyde
Jure Sah
2004-09-28 00:30:49 UTC
Permalink
Post by Randall Hyde
Post by Jure Sah
I am wondering if attempts to make ASM object-orientated and utilizing a
graphical interface to the coding process has ever been made?
HLA and TASM have object-oriented capabilities.
But to my knowledge, no one has created anything like
Borland's OWL for these assemblers yet.
Mind explaining what Borland's OWL is about?
Post by Randall Hyde
See the HLA Standard Library, for example.
http://webster.cs.ucr.edu
I'll check it. Thanks.
Post by Randall Hyde
All Win32 GUI
programming is done using the Win32 API. Under Linux,
it's calls to the GNOME API (or whatever window manager
you're using) which isn't OO IIRC.
[...]
Post by Randall Hyde
But why not make it portable between Win32 and Linux?
Now that would be really neat.
Well I am yet to suceed in installing GNOME on my box... last time I
tried it seemed like there was a neverending stream of dependencies, one
of which just wouldn't install when downloaded.

Other than that I still have to learn C or something I can actually use
in Linux for starters. (I'm lazy ;)

My idea of portability otherwise (given my experience in programing so
far) is not to create a program that will compile everywhere, but to set
up a standard for the datakeeping and then seperate programs that
utilize each OS to the best of their abbility seperately. Tends to save
a lot of nerve as well as allow for more portability (between GNOME and
X11, for example ;).
Post by Randall Hyde
Someday, well in to the future, once I get HLA v2.0 operational,
So you can't install it either, eh? :))
Post by Randall Hyde
my goal is to begin work on a portable GUI library that allows one
to write GUI apps that recompile under Linux, Win32, BSD, and
other x86 OSes (GNOME or Win32 based). Maybe even BeOS.
Using the hardware VGA instructions for this seems to be the universial
solution. Works under any OS. ;)

Anyway, I get your idea... using objects of ASM code that are
interchangable depending on the machine they happen to be 'compiling'
on. However, remind me if I'm mistaken, but isn't that exactly C? =P
Post by Randall Hyde
Obviously, I have an interest in this. :-) But I have other priorities
right now.
I'll be working on this in my free time. (Here is so far:
http://dustworld.dyndns.org/x/moonlink.gif ) It won't take much to do
the innitial version, it's mainly working on the GUI... After that I can
link it to an organizer application to make it automatically select
modules in accordance to the hardware it is intended for.

...and OMG it's 3 am. =P ...TTYL.
--
Primary function: Coprocessor
Secondary function: Cluster commander
Percival
2004-09-28 01:05:13 UTC
Permalink
Post by Jure Sah
Post by Randall Hyde
All Win32 GUI
programming is done using the Win32 API. Under Linux,
it's calls to the GNOME API (or whatever window manager
you're using) which isn't OO IIRC.
[...]
You could use GTK+... though i haven't really used it much . Supposedly
it is a windows manager that works in both Windows and Linux. Couple
with a few cross platform threads, and you are ready to go. (SDL is the
only one that comes to mind...)
Post by Jure Sah
Post by Randall Hyde
But why not make it portable between Win32 and Linux?
Now that would be really neat.
Well I am yet to suceed in installing GNOME on my box... last time I
tried it seemed like there was a neverending stream of dependencies, one
of which just wouldn't install when downloaded.
Try Debian, automatically downloads any dependancies with "apt-get
install (name of package)"

Or just try out aptitude in Debian, and select "install desktop
environment" and it will do most of everything for you.
Post by Jure Sah
Other than that I still have to learn C or something I can actually use
in Linux for starters. (I'm lazy ;)
Nasm assembler works in both Linux and Windows. Gas, Fasm, and HLA are
also good alternatives (and all exceed my expectations in macro
abilities, except gas, of which i haven't used yet)

And I have seen plenty of code compile and run in both Windows and Linux
with the touch of the compile button. Of course, it is slightly harder
work than C or C++, but still possible.
Post by Jure Sah
Post by Randall Hyde
Someday, well in to the future, once I get HLA v2.0 operational,
So you can't install it either, eh? :))
He is writing HLA 2.0.
Post by Jure Sah
...and OMG it's 3 am. =P ...TTYL.
OMG, time zone difference of, quite a few hours :)

Percival
Jure Sah
2004-09-28 05:57:41 UTC
Permalink
Post by Percival
Post by Jure Sah
Post by Randall Hyde
All Win32 GUI
programming is done using the Win32 API. Under Linux,
it's calls to the GNOME API (or whatever window manager
you're using) which isn't OO IIRC.
You could use GTK+... though i haven't really used it much . Supposedly
it is a windows manager that works in both Windows and Linux. Couple
with a few cross platform threads, and you are ready to go. (SDL is the
only one that comes to mind...)
Or just make it all work for CygWin? =PP
Post by Percival
Post by Jure Sah
Well I am yet to suceed in installing GNOME on my box... last time I
tried it seemed like there was a neverending stream of dependencies,
one of which just wouldn't install when downloaded.
Try Debian, automatically downloads any dependancies with "apt-get
install (name of package)"
Or just try out aptitude in Debian, and select "install desktop
environment" and it will do most of everything for you.
My server since it is running has many many users who would be really
upset even over a second of downtime. What do you suggest in this case?
I have a 3rd party + old RedHat mix.
Post by Percival
Post by Jure Sah
Other than that I still have to learn C or something I can actually
use in Linux for starters. (I'm lazy ;)
Nasm assembler works in both Linux and Windows. Gas, Fasm, and HLA are
also good alternatives (and all exceed my expectations in macro
abilities, except gas, of which i haven't used yet)
And I have seen plenty of code compile and run in both Windows and Linux
with the touch of the compile button. Of course, it is slightly harder
work than C or C++, but still possible.
Of course. Now I know many languages just have to pick and I'm trying to
avoid having to learn some of that impossible C++ syntax... but anyway,
I'll see. =P I might end up doing it all in XBasic in the end. =P
Post by Percival
Post by Jure Sah
Post by Randall Hyde
Someday, well in to the future, once I get HLA v2.0 operational,
So you can't install it either, eh? :))
He is writing HLA 2.0.
Oh. =P

Oops. =P
--
Primary function: Coprocessor
Secondary function: Cluster commander
Percival
2004-09-28 20:15:33 UTC
Permalink
Post by Jure Sah
Post by Percival
Post by Randall Hyde
All Win32 GUI
programming is done using the Win32 API. Under Linux,
it's calls to the GNOME API (or whatever window manager
you're using) which isn't OO IIRC.
You could use GTK+... though i haven't really used it much .
Supposedly it is a windows manager that works in both Windows and
Linux. Couple with a few cross platform threads, and you are ready to
go. (SDL is the only one that comes to mind...)
Or just make it all work for CygWin? =PP
CygWin in my opinion, completly sucks. But whatever floats your boat.
Post by Jure Sah
My server since it is running has many many users who would be really
upset even over a second of downtime. What do you suggest in this case?
I have a 3rd party + old RedHat mix.
Sorry, never used RedHat. Though, i heard that RedHat had a similar utility.
http://www.aplawrence.com/Linux/aptget.html

The first hit on google, you may find better sources, but that seems
like a good place to start. Look for "apt-get for redhat" in google.
Post by Jure Sah
Of course. Now I know many languages just have to pick and I'm trying to
avoid having to learn some of that impossible C++ syntax... but anyway,
I'll see. =P I might end up doing it all in XBasic in the end. =P
What is this XBasic?
Jure Sah
2004-09-28 20:48:45 UTC
Permalink
Post by Percival
Post by Jure Sah
Or just make it all work for CygWin? =PP
CygWin in my opinion, completly sucks. But whatever floats your boat.
I was being sarcastic.
Post by Percival
Post by Jure Sah
Of course. Now I know many languages just have to pick and I'm trying
to avoid having to learn some of that impossible C++ syntax... but
anyway, I'll see. =P I might end up doing it all in XBasic in the end. =P
What is this XBasic?
A Basic that is portable between Windows and Linux... It was written in
itself and uses a compiler that compiles Basic to C.

It's not exactly a good language of choice, but it works. =P
--
Primary function: Coprocessor
Secondary function: Cluster commander
Percival
2004-09-28 21:31:04 UTC
Permalink
Post by Jure Sah
Post by Percival
Post by Jure Sah
Or just make it all work for CygWin? =PP
CygWin in my opinion, completly sucks. But whatever floats your boat.
I was being sarcastic.
Hard to tell on the internet.
Post by Jure Sah
Post by Percival
Post by Jure Sah
Of course. Now I know many languages just have to pick and I'm trying
to avoid having to learn some of that impossible C++ syntax... but
anyway, I'll see. =P I might end up doing it all in XBasic in the end. =P
What is this XBasic?
A Basic that is portable between Windows and Linux... It was written in
itself and uses a compiler that compiles Basic to C.
It's not exactly a good language of choice, but it works. =P
Wow, another language written in itself.


Percival
a***@NOW.AT.arargh.com
2004-09-28 23:16:37 UTC
Permalink
On Tue, 28 Sep 2004 22:48:45 +0200, Jure Sah <***@guest.arnes.si>
wrote:

<snip>
Post by Jure Sah
Post by Percival
What is this XBasic?
A Basic that is portable between Windows and Linux... It was written in
itself and uses a compiler that compiles Basic to C.
When did XBasic start having anything to do with C? All the versions
that I have output some sort of assembler, that gets assembled by part
of XBasic.
Post by Jure Sah
It's not exactly a good language of choice, but it works. =P
If you don't mind the somewhat awkward syntax and the fact that you
have to live with it's GUI interface. (Unless that's been changed)
--
Arargh409 at [drop the 'http://www.' from ->] http://www.arargh.com
BCET Basic Compiler Page: http://www.arargh.com/basic/index.html

To reply by email, remove the garbage from the reply address.
Jure Sah
2004-09-29 13:47:16 UTC
Permalink
Post by a***@NOW.AT.arargh.com
Post by Jure Sah
Post by Percival
What is this XBasic?
A Basic that is portable between Windows and Linux... It was written in
itself and uses a compiler that compiles Basic to C.
When did XBasic start having anything to do with C? All the versions
that I have output some sort of assembler, that gets assembled by part
of XBasic.
It seems I must have mixed it with another Windows/Linux Basic in that
case, because as I remember it from approx 2 or 3 years ago, it compiled
to C++, which could then be further compiled to whatever you wanted to
use it on. I know it was so because I remember sending the compiled code
to my coworker who reminded me it was not C but likely C++ according to
the syntax.
Post by a***@NOW.AT.arargh.com
Post by Jure Sah
It's not exactly a good language of choice, but it works. =P
If you don't mind the somewhat awkward syntax and the fact that you
have to live with it's GUI interface. (Unless that's been changed)
It has not been changed.

And the main problem actually is that it's not been very ported for
Windows/Linux but actually only has the commands that can work on both's
hardware abstraction layers... Windows/DOS Basics can translate directly
to DOS and Standard PC (emulated) instructionset (INT ??h) rather well,
obviously in Linux you can't use a DOS instructionset, so a lot of the
commands have been stripped out, as well as a few VGA instructions a
reason for which remains a mistery to me. The point is that you can't
make a GUI for a program the standard Basic way which makes it
practically useless as a porting tool.
--
Primary function: Coprocessor
Secondary function: Cluster commander
a***@NOW.AT.arargh.com
2004-09-29 18:59:06 UTC
Permalink
Post by Jure Sah
Post by a***@NOW.AT.arargh.com
Post by Jure Sah
Post by Percival
What is this XBasic?
A Basic that is portable between Windows and Linux... It was written in
itself and uses a compiler that compiles Basic to C.
When did XBasic start having anything to do with C? All the versions
that I have output some sort of assembler, that gets assembled by part
of XBasic.
It seems I must have mixed it with another Windows/Linux Basic in that
case, because as I remember it from approx 2 or 3 years ago, it compiled
to C++, which could then be further compiled to whatever you wanted to
use it on. I know it was so because I remember sending the compiled code
to my coworker who reminded me it was not C but likely C++ according to
the syntax.
Maybe. The one I know about now comes from here:
http://www.xbasic.org/ but I only have old versions.
Post by Jure Sah
Post by a***@NOW.AT.arargh.com
Post by Jure Sah
It's not exactly a good language of choice, but it works. =P
If you don't mind the somewhat awkward syntax and the fact that you
have to live with it's GUI interface. (Unless that's been changed)
It has not been changed.
And the main problem actually is that it's not been very ported for
Windows/Linux but actually only has the commands that can work on both's
hardware abstraction layers... Windows/DOS Basics can translate directly
to DOS and Standard PC (emulated) instructionset (INT ??h) rather well,
obviously in Linux you can't use a DOS instructionset, so a lot of the
commands have been stripped out, as well as a few VGA instructions a
reason for which remains a mistery to me. The point is that you can't
make a GUI for a program the standard Basic way which makes it
practically useless as a porting tool.
That's not the way I remember XBasic.
--
Arargh409 at [drop the 'http://www.' from ->] http://www.arargh.com
BCET Basic Compiler Page: http://www.arargh.com/basic/index.html

To reply by email, remove the garbage from the reply address.
Beth
2004-09-28 15:40:01 UTC
Permalink
Post by Jure Sah
Post by Randall Hyde
Post by Jure Sah
I am wondering if attempts to make ASM object-orientated and utilizing a
graphical interface to the coding process has ever been made?
HLA and TASM have object-oriented capabilities.
But to my knowledge, no one has created anything like
Borland's OWL for these assemblers yet.
Mind explaining what Borland's OWL is about?
Actually, since Delphi's success, Borland now use the "VCL" (for C++
Builder and such)...though, it's the same basic idea in both cases...the
VCL is appropriate for Delphi / C++ Builder "dragdropiness", if you know
what I mean (no, as you may guess, "dragdropiness" is not a real technical
term but I don't really know how else to describe it ;)...it's a redesigned
and rewritten OWL, so to speak, for their "visual development" stuff...

"Very good", you think, "but what's OWL, anyway?"...

Ah, well...the basic idea is very simple...it's just a "GUI library",
basically...rather than write your own user interface code, you can just
pull out "windows" and "buttons" and "canvases" and such things from the
library...Borland have written the actual user interface code and "wrapped"
it all in a bunch of C++ classes...that's where the OOP comes into
things...it's all implemented as a big "hierachy" of OOP classes (where
they "inherit" common stuff from each other...like every "control" is
ultimately a "child window"...so, they put all the common window stuff into
some "TWindow" class or whatever...and all "controls" can "inherit" from
that...that's why it's a "hierarchy"...but, basically, this is mostly
"implementation detail", anyway...the basic point is that you can just pull
out classes for things like "buttons" and "listboxes" and whatever from the
library :)...

The difference between OWL and the later VCL from Borland is only that they
redesigned things specifically to help support the "visual programming" of
Delphi (and, later, C++ Builder did the same thing with C++ rather than
Pascal as the central language, both made "compatible" to use the same
"VCL" library :)...

Or, another - perhaps simpler - way to put it, is that OWL is Borland's
version of Microsoft's MFC (with regard to GUI components)...and the later
VCL from Borland is the "new improved version" of OWL designed to fit in
with their whole "visual programming" stuff in Delphi and C++ Builder...

As Jure Sah actually stated "utilizing a graphical interface to the coding
process" in his original question, Randy really should have said "VCL" and
not "OWL"...but, as noted, they really are the exact same idea...VCL is
just "re-implemented" OWL in order to make it fit in nicely with the
"visual programming" model (which is Jure's "utilizing a graphical
interface to the coding process" in different wording ;)...

[ Oh, for the record, not that I much ever care about what things "stand
for" in acronyms but it might help some people appreciate what they are:
OWL stands for "Object Window Library", VCL stands for "Visual Component
Library" and MFC stands for "Microsoft(R) Foundation Classes(R)TM"...

So, as you can see, VCL has "Visual" in its name...also, Borland have
better names because they actually bother to, you know, say that these
things are _libraries_ and stress that they are "object-based" or "visual"
in the name too...whilst simultaneously, with "OWL", giving it a funny
"English word" name too...whereas, you can rely on Microsoft to prefix
their name inside the acronym itself and insert the word "foundation" which
means nothing and is totally misleading...the "foundation" of what exactly?
Nothing...it's, in fact, a _middle man_ as a code library, sitting _above_
the "foundations" of the Win32 API...only "classes" tells you anything
useful, that there's some OOP "classes" in there somewhere (well, maybe
not, they also use the word "class" sometimes when it has nothing
specifically to do with OOP)...good old Microsoft...you can rely on them to
supply meaningless, misleading names with "Microsoft(R)" prefixed in front
of everything...indeed, it's surprising it isn't "MMFMC" as "Microsoft(R)
Microsoft(R) Foundation Microsoft(R) Classes" or something...

"Sir" Bill clearly has a serious ego problem and a big "inferiority
complex", convinced everyone would somehow "forget" his empire of evil just
because it might forget the "Microsoft(R)" prefix somewhere...I mean,
"Microsoft(R)" is written multiple times on the Windows loading screen (it
makes sense to be on the copyright notice, of course...but what's the
excuse elsewhere?), which itself is, of course, nothing more than an
"advert" to look at while you're waiting for the darn thing to load,
anyway...and, once it loads, there's the Windows logo on the "Start"
menu...open that - using the Windows logo key on your keyboard that's not
even manufactured by Microsoft for a machine that doesn't even necessarily
have to run Windows in any way that there is no "right" or logic for the
logo to be stamped on the keyboard, other than that Microsoft(R) _FORCE_ it
onto there (or you don't get yourself a "designed for" badge...with which
Microsoft dupes the general public - without explicitly saying so because
it would, of course, be a lie, in fact - into believing "implicitly" that
the absence of a "designed for Windows" badge means Windows won't run or
something...total crap, of course...my machine has the "boycott" badge of
"Powered by Red Hat" on it instead...I'm seriously considering getting
replacement Penguin keys to pop out the Windows key and replace
them...though, I'd prefer if there was some more basic and amusing
"obvious" badges available...you know, "powered by electricity" or
"designed for general purpose data processing" or "microchips by lots of
different manufacturers inside!"...well, it's more honest and accurate,
isn't it? ;) - and (depending on settings but "by default") "Microsoft" is
written down the side of that menu...then there's the Windows logo in the
top right corner of the Explorer windows (replaced by an Internet Explorer
logo in the "Microsoft(R)" prefixed Internet Explorer...though, Outlook
Express uses the Windows logo rather than the Outlook logo)...

Oh, and just in case you still haven't got the message of who wrote Windows
somehow (which seems to require you to be blind and deaf and have no
connection to reality at all...because it's such common knowledge, anyway,
without the logos and things, so much so that most people on the face of
planet Earth know who Bill Gates - just "the bloke who owns it all" - is
without any introductions...who owns McDonald's? Exactly...and that even
has a "clue" in the name that someone called "McDonald" must have at least
started the company at some point ;), "Microsoft Sam" will happily read out
all the hundreds of instances of "Microsoft" covering your screen
(including being specially programmed to say "Microsoft Windows logo"
whenever it discovers the logo on a page...why on Earth does a blind person
need to know there's a logo there at all? If they've been blind all their
life, they have no idea what the "Microsoft Windows logo" looks like...

This is evidence of a pretty serious psychological "inferiority complex"
from Mr.Gates and his mates...this goes way, way beyond "advertising"
towards "golden cow" false idols or something...bow before your "Emperor",
hail the Glory of Redmond! Nice try, ma'am, to give him an honourary "Sir"
prefix (not that he technically can actually use it because he's an
American) in an attempt to perhaps shut him up with all those "Microsoft"
prefixes everywhere, by giving a _real_ prefix "title" to show off to
people with ("hey, I'd be a 'Sir', you know, if I was British...beat
that!")...a white not-really-a-knight in distinctly rusty armour...lucky
for the Queen that "knights" are only ceremonial titles these days (a
method to "honour" someone for "doing good works" :) or, if charged with
her protection, he'd probably just sell her to Bin Laden as a hostage for a
buck fifty...well, it'd be a "profit" for him, wouldn't it? ;) ]
Post by Jure Sah
Post by Randall Hyde
All Win32 GUI
programming is done using the Win32 API. Under Linux,
it's calls to the GNOME API (or whatever window manager
you're using) which isn't OO IIRC.
[...]
Post by Randall Hyde
But why not make it portable between Win32 and Linux?
Now that would be really neat.
Well I am yet to suceed in installing GNOME on my box... last time I
tried it seemed like there was a neverending stream of dependencies, one
of which just wouldn't install when downloaded.
What "distro" are you using? The simple method is to use a "distro" that
automatically installs it with Linux...or one that can use the "RPM"
installation method (surely GNOME can be got in an "RPM"? I don't
know...just guessing ;)...

I prefer KDE's style, anyway...looks better...
Post by Jure Sah
Other than that I still have to learn C or something I can actually use
in Linux for starters. (I'm lazy ;)
<PLUG SHAMELESSLY_BLATANT="YES">

Hey, no need to learn C once LuxAsm is up and running! ;)

</PLUG>
Post by Jure Sah
My idea of portability otherwise (given my experience in programing so
far) is not to create a program that will compile everywhere, but to set
up a standard for the datakeeping and then seperate programs that
utilize each OS to the best of their abbility seperately. Tends to save
a lot of nerve as well as allow for more portability (between GNOME and
X11, for example ;).
Hallelujah! Someone's got it, at last! :)

Yes, there are many different _types_ of "portability" (even though it is
often spoken of as if some all-or-nothing binary attribute..."is your
program portable?" is NOT actually a "yes" or "no" question but more of a
"it's source-level but not binary compatible...doesn't utilise UNICODE,
follows the OpenGL standard, etc., etc." answer should come out of that
question ;)...

And one of the most elegant "portability" solutions is simply
"standardisation"...to define a platform-independent "standard" and then,
as you say, each OS can implement it as best as possible to the specific
machine...this is what X uses, the internet protocols use, UNIX uses ("de
facto"), Java uses, etc., etc....X is a particularly nice example because,
for instance, it uses a simple solution to "endianness"...when setting up a
"connection" to an X server, the client sends a "byte order mark" as its
first message to the server...then all communications happen in that
endianness thereafter...

Potentially more efficient than the internet's "network order is
big-endian" throughout...kind of proved by the unfortunate accident that
the majority of the world's machines are x86 based - which is little
endian - and, thus, most internet communications are being continually
"byte swapped" all the time...kind of funny, really...the numbers get "byte
swapped" to be sent and then, once they reach the destination, they are
"byte swapped" straight back to what it already was originally...physically
speaking, there's no need to swap anything at all in that situation...they
had the sense, though, to make the IP address a series of _bytes_ that we
don't get constant "byte swapping" all along the chain of "propogation"
(because, of course, internet messages rarely go directly to their
destination but have to be "propogated" from server to server (which, at a
minimum, has to read the IP address of the destination out of the packet to
know where to be delivering it next ;)...hence, consider having to "byte
swap" just to read the packet to know where to deliver it: "packet -> byte
swap -> ISP -> byte swap -> read -> byte swap -> next server -> byte
swap -> read -> byte swap -> next server -> byte swap -> read -> byte
swap -> destination -> byte swap -> use"...a ludicrous situation, really,
when, chances are, every machine in the chain is, in fact, little endian
(an x86, probably) so there was no physical reason whatsoever to perform
even one byte swap, other than to fit in with the "standard" :)...

X's method to deal with "endianness" is a little better in that it sends a
"byte order" message to say "hello, Mr.Server, I'm a little-endian machine"
when it first connects (and from then on, the connection is set at this
endianness...which makes sense, because CPUs usually don't suddenly change
"endianess" half-way through communications or anything...it's one of those
"up front" solutions...sort it all out _ONCE_ at "initialisation" rather
than continually pay a "portability" cost with every packet / message /
whatever ;)...then it's - here's the clever bit - up to the server how it
wants to exactly _implement_ that...it could use the same code and some
"endianess" flag...it could have separate hard-wired "big endian" and
"little endian" code (trading a little "code size" for some "speed"...now
the only "endianness" problems are the ones you can't avoid because the
machines are _physically_ different "endianness" :)...

X has a few examples of this smart use of "restraint"...you know, when it's
smart to specify and when it's actually far, far smarter to "use restraint"
and NOT specify something...the act of NOT specifying something in a
standard can be as smart and effective as specifying things...how do jazz
musicians like to phrase it? "It's not just the notes we're playing, it's
the notes we _aren't_ playing"...the gaps between the notes are just as
important as the actual notes played...good music is as much about dischord
as it is harmony...about the timing between notes as much as the duration
of the notes themselves (playing "pizzicato" - short stunted notes or,
taking a negative perspective, playing long "gap" non-notes - is found just
as much in classical music as playing funky guitar as in a techno bassline
;)...

Hence, X doesn't specify things like the "endianness" outright like the
internet protocols do...it specifies a means for machines to communicate
their "endianness" to each other (how the X server actually wants to deal
with this is an "implementation detail"...one of the smart things that the
X standard uses "restraint" to NOT specify ;)...and X specifies the
"requests" and "events" (collectively: the messages between client and
server...the terms reflect the direction..."request = client -> server",
"event = server -> client" ;)...what messages there are, the format of the
data packets, etc....but it doesn't specify the actual "transport" on which
those messages are sent...again, a smart use of _RESTRAINT_ in the standard
to know when to leave things as "implementation details"...hence, the
"transport" can potentially be selected according to the situation (for
instance, an X implementation could choose to use "sockets" for remote
communications while using direct IPC - a queue or shared memory or
something - when both client and server are "local" to reduce
"overhead"...it can also select a different caching policy for both...for
the "remote" connection, it can try to cache as much as possible to
conserve bandwidth...but for "local" connections, it can instead prioritise
_responsiveness_ rather than throughput, as "bandwidth" is typically a
non-issue...unfortunately, not all X implementations seem to have realised
that the lack of specification was _delibrate_ to allow this ability to
actually _change_ "transports" and caching policies to prioritise either
responsiveness or throughput, according to the type of connection
needed...by just saying "it is cached" but not specifying anything specific
like the size or "policy" of that caching, the implementation can select
different caching policies that are appropriate to the specific
situation...indeed, including a caching policy of "write through" that it
doesn't cache at all, if that ever made sense as a good idea :)...

There are many, many examples of "portability" where the implementors
clearly don't "get" it whatsoever...unsurprisingly, Microsoft have a nice
example in the Win32 API...
Post by Jure Sah
Post by Randall Hyde
Someday, well in to the future, once I get HLA v2.0 operational,
So you can't install it either, eh? :))
Post by Randall Hyde
my goal is to begin work on a portable GUI library that allows one
to write GUI apps that recompile under Linux, Win32, BSD, and
other x86 OSes (GNOME or Win32 based). Maybe even BeOS.
Using the hardware VGA instructions for this seems to be the universial
solution. Works under any OS. ;)
Anyway, I get your idea... using objects of ASM code that are
interchangable depending on the machine they happen to be 'compiling'
on. However, remind me if I'm mistaken, but isn't that exactly C? =P
Post by Randall Hyde
Obviously, I have an interest in this. :-) But I have other priorities
right now.
http://dustworld.dyndns.org/x/moonlink.gif ) It won't take much to do
the innitial version, it's mainly working on the GUI... After that I can
link it to an organizer application to make it automatically select
modules in accordance to the hardware it is intended for.
...and OMG it's 3 am. =P ...TTYL.
--
Primary function: Coprocessor
Secondary function: Cluster commander
Beth
2004-09-29 06:42:31 UTC
Permalink
[ I accidentally hit "send" again before finishing (it's like buses, isn't
it? I don't do that for years, then do it three times in a row
;)...regardless, as it turns out that Jure doesn't mean "object-orientated"
in the same way most other people do (as C notes, this sounds more like a
CASE tool or something), there's probably no point picking up the post from
where I accidentally sent it...but, thinking about it, as it kind of stops
mid-stream, promising an example that never shows up, I should probably
post this to explain...I hit the wrong set of keys and sent it before I'd
meant to do so...but I do think I now know what exactly is happening...I'm
used to tapping ALT + F then S ("File" -> "Save" :) instinctually to save
something...Microsoft have cleverly confused things by making ALT + S as
the "send" key...hence, when tapping ALT + F then S, I wasn't pressing the
"F" key properly or something...ah, good old Microsoft...it'll pester me
with "are you sure?" for practically everything else _except_ where it
might actually be useful to ask that question ;) ]

Beth :)
Annie
2004-09-29 08:19:46 UTC
Permalink
[ From header: ] 06:42:31 GMT
You're up early, Beth.
I accidentally hit "send" again before finishing (it's like buses,
isn't it? I don't do that for years, then do it three times in a
row ;)...
_____
Ummmm...how is that "like buses?" ((( `\
_ _`\ )
Or is that phrase some sort of (^ ) )
Brit slang that's incomprehen- ~-( )
sible to the rest of the world? _'((,,,)))
,-' \_/ `\
Well, just remember, Beth: men ( , |
are like buses. If you miss one, `-.-'`-.-'/|_|
another will be along shortly. \ / | |
Hehehe! =()=: / ,' aa
Beth
2004-10-01 19:01:18 UTC
Permalink
Post by Annie
Post by Beth
I accidentally hit "send" again before finishing (it's like buses,
isn't it? I don't do that for years, then do it three times in a
row ;)...
Ummmm...how is that "like buses?"
Ah, sorry...I thought the joke was more internationally known but, clearly,
it's "regional"...the joke is an example of Murphy's Law in action...that
you can sit around all day waiting for a bus and none comes, then, once
you're about to leave, three buses turn up at the same time...it's like a
running joke around here...everyone else is thinking "what?!?"...but all
the Brits are thinking: "ah, yes...like buses...very much like
buses...three buses, no less...very good"...

Ah, we're all "surrealists" on this isle...this is "amusing" in our
book...just pay no attention...

Oh, wait...that's right...you never do, anyway, do you? ;)

Beth :)
Betov
2004-09-28 06:06:36 UTC
Permalink
Post by Jure Sah
Hello,
I am wondering if attempts to make ASM object-orientated and utilizing a
graphical interface to the coding process has ever been made?
The only one i ever heard about is at:

< http://www.szmyggenpv.com/RosAsm.htm >

Unfortunately, for you, this is not Linux... ;)


Betov.

< http://betov.free.fr/RosAsm.html >
Betov
2004-09-28 10:54:07 UTC
Permalink
Post by Jure Sah
Hello,
I am wondering if attempts to make ASM object-orientated and
utilizing a
graphical interface to the coding process has ever been made?
[...]
It seems i completely miss-understood the question. :))


Betov.

< http://betov.free.fr/RosAsm.html >
wolfgang kern
2004-09-28 09:35:49 UTC
Permalink
Jure Sah wrote:

| I am wondering if attempts to make ASM object-orientated and utilizing a
| graphical interface to the coding process has ever been made?

| If yes, screenshots please.

| Otherwise, is it optimal to be using many 'subroutines' in an ASM
| program, blocks of code designed for a specific purpose (such as for
| example exporting a string to a file, etc), which the program then jumps
| to and returns whenever there is a need for it, in your oppinion?

| I am thinking of making a graphical interface where ASM code can be put
| in objects where registers and the data pointers can be 'tied togather'
| using a mouse, and the program then just makes the "MOV x,y"s and
| "JMP"s, puts the code togather all in the right order, and passes the
| finnished ASM code to whatever the user's assembler happens to be. The
| second idea is then that these objects would be exportable as files and
| shareable as well as groupable into bigger objects.

| I'd need such an interface for my personal needs but I would of course
| make it freeware.

| Is this already done somewhere? Is your personal oppinion that such an
| interface would be useless?

I think 'G' may be similar to what you are searching for, its variants
(I used G-LabView for some years) offer graphical drag&drop features
and allow data and code insertion in already prepared boxes.
I haven't checked if the latest versions still support ASM-Inline code.

This tool was quite expensive (>U$5000), awful slow and the produced
executables were heavy bloated.

My final target is also an graphical application-builder
(for KESYS only), but I cannot start with it until everything
planned to add to my system is finished.
So all I got now are many ideas and a raw concept.

An ASM-G would really be a good tutorial and would help ASM
to become more popular, but I'm afraid this is a hell of a job.

Good Luck!
__
wolfgang
Jure Sah
2004-09-28 16:08:22 UTC
Permalink
Post by wolfgang kern
I think 'G' may be similar to what you are searching for,
"G"?
Post by wolfgang kern
its variants
(I used G-LabView for some years) offer graphical drag&drop features
and allow data and code insertion in already prepared boxes.
I haven't checked if the latest versions still support ASM-Inline code.
This tool was quite expensive (>U$5000), awful slow and the produced
executables were heavy bloated.
My final target is also an graphical application-builder
(for KESYS only), but I cannot start with it until everything
planned to add to my system is finished.
So all I got now are many ideas and a raw concept.
An ASM-G would really be a good tutorial and would help ASM
to become more popular, but I'm afraid this is a hell of a job.
In the hope that we're talking about the same thing. =P Yes that Was my
idea.

A starters tool in which when you for example want to make an example
screen capture application don't have to end up with a program that will
ocasionaly do what it's supposed to and occasionaly draw paper trough
the printer. You can just take one screen read module, one buffer
module, one disk writer module, tie their plugs togather and assemble.

Being for starters I don't expect people to use it for 1.2 MB+
assembles, but rather for cute, tiny, Fast, easy-to-make utilities.

The tool that inspired me for this is the Buzz tracker, which is an
audio-processing toolset that uses such a GUI for the datastream
pipelineing.
Loading Image...
Post by wolfgang kern
Good Luck!
Thanks.
--
Primary function: Coprocessor
Secondary function: Cluster commander
wolfgang kern
2004-09-29 17:54:37 UTC
Permalink
Jure Sah wrote:

| > I think 'G' may be similar to what you are searching for,
| "G"?

The programmming language 'G'.
It works with icon-tables for logical-operations (many variations).
This icons can be drag/dropped to a "schematic" and they got
input and output "pins" where "wires" can be placed to achieve
more complex functions (this wires can hold strings, arrays and
combined 'data-clusters' in addition to standard data-types).

G-LabView got an extension which allow 'virtual panels'
with all kind of click-buttons and displays from ASCII to radar-scope
and animated 3D-grids.
All elements on this panel are also shown in the 'schematic'.
And finally every panel can be stored as a new icon with almost
infinitive connection-points and nodes.

Many (perhaps too many) options with LabView, but as mentioned,
the resulting code got nothing to do with the programmers ideas
about speed/size-optimised routines.
Perhaps speed and size are the main reasons for 'G' hasn't become
_that_ popular for PC-application programming.

But almost all CAD-systems, layout-routers and chip-designers
use 'G'-similar tools with the drag/drop/connect features.

So Yes, why not one for ASM.

[..]
| > An ASM-G would really be a good tutorial and would help ASM
| > to become more popular, but I'm afraid this is a hell of a job.

| In the hope that we're talking about the same thing.
| =P Yes that Was my idea.

:) seems I got what you said ...

| A starters tool in which when you for example want to make an example
| screen capture application don't have to end up with a program that will
| ocasionaly do what it's supposed to and occasionaly draw paper trough
| the printer. You can just take one screen read module, one buffer
| module, one disk writer module, tie their plugs togather and assemble.

| Being for starters I don't expect people to use it for 1.2 MB+
| assembles, but rather for cute, tiny, Fast, easy-to-make utilities.

Yes, even an analphabetic can write (better draw) a working program
with a graphical tool. :)
I remember some early (during BASIC-area) programming tutorials
for kids like Turtle-Basic on the 'green only' monochrome monitors.

| The tool that inspired me for this is the Buzz tracker, which is an
| audio-processing toolset that uses such a GUI for the datastream
| pipelineing.
| http://pasokon-yugi.cool.ne.jp/image/buzz_machine01.gif

I'll look at it.

__
wolfgang
Jure Sah
2004-09-30 18:54:37 UTC
Permalink
Post by wolfgang kern
| > I think 'G' may be similar to what you are searching for,
| "G"?
The programmming language 'G'.
It works with icon-tables for logical-operations (many variations).
This icons can be drag/dropped to a "schematic" and they got
input and output "pins" where "wires" can be placed to achieve
more complex functions (this wires can hold strings, arrays and
combined 'data-clusters' in addition to standard data-types).
G-LabView got an extension which allow 'virtual panels'
with all kind of click-buttons and displays from ASCII to radar-scope
and animated 3D-grids.
All elements on this panel are also shown in the 'schematic'.
And finally every panel can be stored as a new icon with almost
infinitive connection-points and nodes.
Ahh yes, just like Electronics WorkBench. OK. :)
Post by wolfgang kern
Many (perhaps too many) options with LabView, but as mentioned,
the resulting code got nothing to do with the programmers ideas
about speed/size-optimised routines.
Perhaps speed and size are the main reasons for 'G' hasn't become
_that_ popular for PC-application programming.
It likely had an abstraction layer, like most modern programming languages.
Post by wolfgang kern
But almost all CAD-systems, layout-routers and chip-designers
use 'G'-similar tools with the drag/drop/connect features.
So Yes, why not one for ASM.
And how many components was it possible to have on screen at once
(before they are grouped down into objects that contain other objects)?
I am having some problems with allocating 'infinite' memory space for
the objects, because a 2D board is not as simple to map to memory as a
linear programming language display.
Post by wolfgang kern
| In the hope that we're talking about the same thing.
| =P Yes that Was my idea.
:) seems I got what you said ...
;)
Post by wolfgang kern
| Being for starters I don't expect people to use it for 1.2 MB+
| assembles, but rather for cute, tiny, Fast, easy-to-make utilities.
Yes, even an analphabetic can write (better draw) a working program
with a graphical tool. :)
I remember some early (during BASIC-area) programming tutorials
for kids like Turtle-Basic on the 'green only' monochrome monitors.
The problem of course is that with any ASM, you still have to know what
you're doing. I hope that my linking program will not encounter any
problems that would require intelligent solving. But even if it ends up
rather un-optimized, I have this feeling ASM code will always be smaller
and faster than most programming languages.

I'll make it... right after I meet a deadline or two at work of course. ;)
--
Primary function: Coprocessor
Secondary function: Cluster commander
C
2004-10-01 07:58:48 UTC
Permalink
Post by Jure Sah
The problem of course is that with any ASM, you still have to know what
you're doing. I hope that my linking program will not encounter any
problems that would require intelligent solving. But even if it ends up
rather un-optimized, I have this feeling ASM code will always be smaller
and faster than most programming languages.
No, assembler is smaller and faster _because_ it is optimised. If you
make a tool which generates unoptimised assembly it will be no better
than a HLL compiler and probably worse. What makes assembler fast is
that it gives greater scope for optimisations than exist with HLLs.

C
2004-10-01
wolfgang kern
2004-10-02 13:04:06 UTC
Permalink
Jure Sah wrote:

[..G-ASM]

| And how many components was it possible to have on screen at once
| (before they are grouped down into objects that contain other objects)?

Just as many as you like, even I'd recommend to limit the count to
stay just readable, my personal record was over 2000 elements,
but I couldn't find a printer for this big one, and the scroll-bars
got a really huge range then. :)

| I am having some problems with allocating 'infinite' memory space for
| the objects, because a 2D board is not as simple to map to memory as a
| linear programming language display.

Yes, large function blocks used virtual memory, which made it very slow.

| The problem of course is that with any ASM, you still have to know what
| you're doing. I hope that my linking program will not encounter any
| problems that would require intelligent solving. But even if it ends up
| rather un-optimized, I have this feeling ASM code will always be smaller
| and faster than most programming languages.

| I'll make it... right after I meet a deadline or two at work of course. ;)

I like the idea, a G-ASM may be able to teach ASM 'like playing a game'.

__
wolfgang

C
2004-09-28 10:12:05 UTC
Permalink
Post by Jure Sah
Hello,
I am wondering if attempts to make ASM object-orientated and utilizing a
graphical interface to the coding process has ever been made?
From the rest of your mail, what you are saying with "object-oriented"
is _not_ what object-oriented means in computer science. Apparently
you are proposing some form of graphical CASE tool which implements
assembly language as a series of data flow diagrams.

The only programming language which works like this (that I know of)
was a implemented with flow diagrams (I cannot remember the name --
maybe turtle?), my experience with such a language indicated it took
far longer to write even trivial/toy applications than the more normal
text programming techniques. I suspect that programming assembly with
such a technique is likely to take many times longer than programming
with a simple text editor.

CASE tools in general seem to me just to result in more work with
little practicle benifit for most programmes. (Though there is some
benifit with managing large applications.)

Having said this there may be some utility in allowing an assembler
to be able to generate code/data flow diagrams which may make
analysing and navigating of source easier -- though I would keep to
writing source with text tools.

C
2004-09-28
Loading...