From: Wolfgang Kern on

"Betov" �crivait:

>> 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.

A well know story also here...
I just finished a rewrite of my formatted numeric I/O routines and
gained more than 20% speed and saved about 15% space while adding
more features :)
Many parts could be improved by only reorder structs and reuse
already existing code parts.

> 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.

Yes that's the problem, none of all this new 64-bit OS really work,
and I also moved the KESYS64 project to the very end of my TO-DO list.
Seems I just want to wait for a better designed 64-bit CPU :)

KESYS could be a target, but I'm afraid you don't like to type
and code in a script language :)
Perhaps one day I can release a general purpose version of KESYS.

__
wolfgang



From: Wolfgang Kern on

"sevag.krikorian" asked:
....

>> 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? 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.

You, and Rene as well, can't tell at all how many coders use RosAsm ...
The fact that you don't see any questions like "how to install" or
"why wont this work" is not an indication for its population count.

__
wolfgang



From: Robert Redelmeier on
Rosario <Rosario(a)not.exist> wrote in part:
> 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

Targetting a CPU at a HLL has been done many times.
The 8086/8088 has some signs of being targetted at C,
and the 186+ has extentions for PASCAL.

> the assembly programers will program in p-code

It never has worked to the extent of killing
assembly. See Randy's "Great Debate".

-- Robert






From: Betov on
santosh <santosh.k83(a)gmail.com> �crivait news:feavsr$ifd$2(a)aioe.org:

> This whole discussion of backwards binary compatibility is downright
> silly. Just install a VMM like VirtualBox or VMWare and you can run any
> number of OSes to your heart's content

Hey! This is not me who talked about runing DOS files under Linux
nor ELFs under Windows. Right: It was downright and downleft silly.
Your bad.

:))

Betov.

< http://rosasm.org >

From: Betov on
"Wolfgang Kern" <nowhere(a)never.at> �crivait news:feb12g$4jh$2
@newsreader2.utanet.at:

> I just finished a rewrite of my formatted numeric I/O routines and
> gained more than 20% speed and saved about 15% space while adding
> more features :)
> Many parts could be improved by only reorder structs and reuse
> already existing code parts

Sure. It is often times very difficult to understand where time
can be saved. I would now choose something like the CheckSum64
stuff of RosAsm for the Symbols Table. When i applied this, i
was rather surprised of the improvement. From what i have seen,
i suppose that the encoder could be twice faster (at least), by
applying the same method to Mnemonics. Maybe to the Registers
also. What is sure, is that, in matter of speed, it is better
to waste a bit of memory, with big tables, than to think about
directly improving the speed of the code in a parser. This
seems to be always worthy the wasted time at creating the
CheckSum.


Betov.

< http://rosasm.org >



First  |  Prev  |  Next  |  Last
Pages: 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40
Prev: aeBIOS Test Request
Next: CMOVcc vs. Jcc