From: Betov on
//\\\\o//\\\\annabee <w(a)w.w.w> �crivait news:op.tzs8j7ynin6out(a)darth-
fpsr:

> to be able to generate 64 bit apps.

Extending to 64 is a rather trivial task. Around two months of work.

But, for RosAsm there are several additional problems:

1) The Encoder of RosAsm - being the older part of the beast -,
is very durty, and badly written. It deserves a complete
re-organization. Even if the whole Assembler is the fastest
of the actual ones, it should be *way* faster. Look how FASM
is fast, for example, whereas it is multi-passes (against
the mono-pass of RosAsm Encoder): It is close as fast as
RosAsm is. This says all there is to say about it.

2) We do not know where we are going to. A programming tool
like RosAsm, needs a target-OS. To date, we have none, and
this terrific problem is way more important than the details
of 64-bit.


Betov.

< http://rosasm.org >








From: santosh on
Betov wrote:

> santosh <santosh.k83(a)gmail.com> �crivait news:fe8s3n$70p$1(a)aioe.org:
>
>> But now you've boxed yourself with Windows! At least make it output
>> ELF files. You don't need to port the whole IDE to Linux, just the
>> assembler alone would do.
>
> You seem to be missing the concept of RosAsm. Again, the real point
> is with *integration* inside a single IDE for RAD. Without this,
> RosAsm would just mean nothing at all.
>
> So, the strategy i am actually considering is:
>
> * Re-organizing RosAsm Source for grouping all OS calls into
> a dedicated TITLE (for maintaince, in case GTK would not
> be that reliable, at a backward compatibility point of view).
>
> * Port RosAsm itself to GTK. There exists a "GTK for Windows",
> that should make the job a bit easier, saving from having to
> deal with Linux.
>
> * Implement the ELF Format.
>
> * Compile RosAsm as an elf.
>
> My estimation of the work time is around two years. Probably way
> more because of my health.
>
> And, if two or more years, Ubuntu is still in the same state as
> today, this will mean that Linux will never win more than its
> current 1.5% or 2% of the market place (against 90% for Windows).
> Considering the actual number of RosAsm users (around 20, i know
> about), this makes:
>
> 20 / 90 * 2 = around... zero users.
>
> Ubuntu is a more risky bet than ReactOS was 10 years ago, in my
> opinion. And as i am becoming too old for the job, this bet
> sems to me... scaring.
>
> Also, there is the Debugger problem: Without an *Integrated
> Source Level Debugger*, RosAsm would mean nothing, and, as
> a matter of fact, GTK does evidently not offer any Debug
> Api like Windows does. Maybe those Api exist somewhere else
> in Ubuntu (i suppose not), but if a real Processor level
> Debugger is too be re-written, this is again, a couple of
> years of works to be add to the price to pay.

Don't just assume yourself that without all the accessory toys
RosAsm "would be nothing." Let your users make that decision.

You have to start somewhere. All other parts of RosAsm exist _because_
of, and in _service_ to, the core language and it's assembler. So
firstly a working assembler, (not full IDE), for Linux will enable you
gauge it's feasibility under Linux and whether enough user demand
exists. On the way you'll also learn all about ELF format.

_Then_ the basic IDE can, as you say, be implemented with GTK+. This is
a bigger job, since GUI programming is usually more time-consuming than
text based programming.

As you note, the debugger will be the hardest job and you can do it
last. Your users can use ALD in the interim.

From: Betov on
Evenbit <nbaker2328(a)charter.net> �crivait news:1191727157.999327.196710@
57g2000hsv.googlegroups.com:

> I guess you are not aware of the huge success (and still a favorable
> following) of Visual Basic?

�Personally, i never saw Visual Basic. No idea what it *looks like*.
But what is self evident is that people who buy a programming Tool,
buy nothing but a *NAME*. Here, they buy the word *BASIC*, that is,
a "Language for beginners", and *VISUAL*, that is, something where
they will be supposed to create an Application with the mouse only.

This is the whole story of Programming software. You know, there
even exist people who buy the chars "HLA", as meaning "High Level
Assembler"... Market place and reality have poor relationships.


Betov.

< http://rosasm.org >



From: Evenbit on
On Oct 7, 1:11 am, "sevag.krikorian" <sevag.krikor...(a)gmail.com>
wrote:
> On Oct 6, 11:19 pm, Evenbit <nbaker2...(a)charter.net> wrote:
>
> > On Oct 6, 6:13 pm, "sevag.krikorian" <sevag.krikor...(a)gmail.com>
> > wrote:
>
> > > > You compare RosAsm to what???? exactly?
>
> > > The Lisa assembler, another product that tried to insert an editor,
> > > assembler, debugger, etc. into a single application. Face it, people
> > > prefer integrated environments where they may choose the tools to
> > > integrate instead of being stuck with one product that tries to be a
> > > jack of all trades, master of none.
>
> > I guess you are not aware of the huge success (and still a favorable
> > following) of Visual Basic?
>
> I don't follow Visual Basic or any Basic. There may be some niches
> where this concept works.

The corporate world was such a niche, one could say. They loved VB
because they could hire armies of low-paid, poorly-trained High School
and 1-1/2 year Vocational School grads to literally "paint" the front-
ends for enterprize applications. [the role now largely played
by .NET] Hence the popularity of the "VB Code Monkey" phrase.

>
> > There were many attempts amoung compiler
> > vendors (some "big name" corps included) to replicate this phenomenom.
>
> And how did that go?

I believe some focused on vertical markets while others looked like
they could compete with MS, but they failed to execute the necessary
marketing and support strategies to be taken seriously.

>
> > In the ASM community, Spasm/RosAsm succeeded at obtaining the product
> > (including accessory items, examples, etc.. {necessary support
> > framework around the product}) part of the goal where several other
> > attempts [ yes, many incarnations of "Visual Assembly" project, I am
> > looking at you! ] have failed.
>
> > Nathan.
>
> How exactly has Rotty succeeded where others have failed?

It succeeded by becomming an actual, bonafide, real product -- and a
real integrated IDE at that. It also gained the "(including accessory
items, examples, etc.. {necessary support framework around the
product})" attribute.

It got most of the way to this goal when very little else was
available. FASM was yet to be born. HLA was not yet conceived.
MASM32 was available, but Steve's editor didn't satisfy people's
desires. Hence the several aborted "Visual Assembler" attempts. You
can still download some of these incarnations:

http://www.fortunecity.com/skyscraper/lycos/403/
http://www.winsite.com/bin/Info?1000000034965

> RadAsm
> alone has far more users at any given time than Rotty has had in its
> entire history. If that's not a qualification of success then I don't
> know what is.

That is obviously not the type of success I was speaking of.

>
> BTW, HIDE is not a "Visual Assembly" project. It's a project based
> HLA development environment. The only "visual" component is an
> external resource editor and that's included just for convenience.

Hmm? I wasn't referring to HIDE. My earlier joking parenthetical
"[ yes, many incarnations of "Visual Assembly" project, I am looking
at you! ]" contains a rhetorical "you" referring to the above-
mentioned Visual Assembler products and others -- all of which were
best described as "hap-hazard collections" when I had investigated
them during that time period. Wish I had saved some of those zip
files so that I could show what they were like.

Nathan.

From: Rosario on
In data Sun, 07 Oct 2007 09:03:10 +0200, Rosario scrisse:
>so the poor low level programmer have to rewrite the same programme
>each environments or he/she have or use a very high hll language like
>java ...
>
>i think it is better that hardware people has some consensus for a
>minimal cpu mode (30 to 50 instructions n� x registers of
>8,16,32,[64?]bits registers, AND, OR, PUSH , JMPS, CALL, etc etc and
>fpu too)
>
>or a minimal enviromets ()
>
>so define an assembly language for that cpu; so c or c++ compiler can
>produce assembly for that cpu and so to be portable by hex, and
>assembly programmers can have a cross cpu to program
>
>the same the Operative Systems people can define a set of command
>cross OS for doing "visual" programming
>
>all this because the cost of software seems bigger than cost of
>hardware so programs have to be maximus portable
>
>but possible this is an error, i write errors

wrong
i think in the future cpu vendors will inprove the cpu so java p-code
or C# p-code or phiton p-code is more fast

the assembly programers will program in p-code

First  |  Prev  |  Next  |  Last
Pages: 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34
Prev: aeBIOS Test Request
Next: CMOVcc vs. Jcc