Prev: aeBIOS Test Request
Next: CMOVcc vs. Jcc
From: Wolfgang Kern on 7 Oct 2007 10:35 "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 7 Oct 2007 10:46 "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 7 Oct 2007 12:21 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 7 Oct 2007 12:27 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 7 Oct 2007 12:51
"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 > |