Release of RosAsm V.2.025a
in [ASM]
|
From: Betov on 19 Sep 2005 08:09 "wolfgang kern" <nowhere(a)nevernet.at> ?crivait news:dgm8sm$ep$1(a)newsreader1.utanet.at: >| Idem. Mind you, any "Home made Assembler" Author can >| easily output obj files and rely on an external Linker, >| in 1% of the time that we are investing at developing >| way more serious ways. > > Linking to or include a library would make sense if the libraries > would contain really useful things only. > I haven't found any real good code in any yet. In the team, everybody is in this opinion too. The (demential) work, we are actually doing on the LibScanner - that will take all of this in charge, anyway... - is, first, designed to create a complete D.I.S. system, for the Disassembler. Another story... ;) Betov. < http://rosasm.org >
From: Richard Cooper on 19 Sep 2005 09:47 On Mon, 19 Sep 2005 05:56:48 -0400, Betov <betov(a)free.fr> wrote: > No, he is not _wrong_. He is just introducing a _HUGE_ > ADVANTAGE as an implicit inconvenient. I don't see now not being able to do something can be an advantage. When I write a really nice function, I like to be able to use it in every program that I write, simply by making the file it's in part of the set of source files that make up the program, or by using an include directive. With RosAsm, I'd have to go and copy and paste it into RosAsm, because apparently being able to keep it as a seperate file would be a huge disadvantage. I also don't link to external object code often. Currently the only time I do it is with my "quick little assembly programs" folder that I write simple little programs in. In there I've got my register dump code compiled into an object file, and my script to assemble files links them with that object file. That way I've got all of the debugging support I've developed in every program without having to copy all of that code into every program. However, like you've said, doing it that way is a huge disadvantage. I'd be much better off to just copy and paste that 546 lines of code into every program that I write, that way if I later come up with a better idea for some of the debugging stuff that's in there, I have to go through every program I've made that uses it and update the debugging code seperately. Being able to update them simply by updating a single object file and a single include file would be a huge disadvantage.
From: Betov on 19 Sep 2005 10:06 "Richard Cooper" <spamandviruses(a)xersedefixion.com> ?crivait news:op.sxcq9acx29jixb(a)sucks.airplane.fire: > On Mon, 19 Sep 2005 05:56:48 -0400, Betov <betov(a)free.fr> wrote: > >> No, he is not _wrong_. He is just introducing a _HUGE_ >> ADVANTAGE as an implicit inconvenient. > > I don't see now not being able to do something can be an advantage. Having a Tool that does not push the user to bad programming practice _is_ in _HUGE_ advantage. > When I write a really nice function, I like to be able to use it in > every program that I write, simply by making the file it's in part of > the set of source files that make up the program, or by using an > include directive. With RosAsm, I'd have to go and copy and paste it > into RosAsm, because apparently being able to keep it as a seperate > file would be a huge disadvantage. Utterly wrong. With RosAsm, we store the "nice function" into the Clip File, what is _WAY_ better and _WAY_ more intelligent than going the "Blind-Box" programming way. > I also don't link to external object code often. Currently the only > time I do it is with my "quick little assembly programs" folder that > I write simple little programs in. In there I've got my register > dump code compiled into an object file, and my script to assemble > files links them with that object file. With the RosAsm methods, you don't _have to_ do it this stupid way. Betov. < http://rosasm.org >
From: Guga on 19 Sep 2005 23:36 http://groups.google.com.br/group/alt.lang.asm/browse_frm/thread/2fbb5a4bf7f12ffe/51a1ae1966c44da4?q=annie&rnum=1&hl=en#51a1ae1966c44da4 Richard ____________________________________________________ About the single (Unique) source, this is not a problem. In fact, it helps to you assemble your source when you don´t have the other(s) external file(s). It is usual (common) when you try to assemble your file, sometimes you get an error message from your assembler (example: masm) saying that it is missing one of the include files (.inc, .asm, or .lib etc). On masm board or win32 asm board for example, many times when i was trying to assemble a project i couldn´t be able to assemble a given source, because the file that were uploaded did not contained one (or more) of the necessary files to be used. If your project have few multiple files..let´s say 02, 3, 5 ...this problem _tend_ to don´t happen that offten (but it surelly happens) , but when you have dozens or hundreds of different sources to be "included" it is easy to happen those kind of errors. So, multiple files are not the proper answer for everything. This is the major disadvantage of having multiple files. On the other hand, with a single file, this problem would never exists. All it needs is someone pass to you his single asm file to you assemble. You don´t need anything more then it. In RosAsm if your source gets big, or if you want to organize the functions on your code, all you need to do is "split" your code internally. I mean, all you need is use the command TITLE to you be able to internally separate your source inside the source editor. So you can actually read in one Tab (Title) a certain function, and in another Tab you can see another function.(Or any other part of the code you want to be separated) ________________________________________________________ Library files and linkage have some problems that we must consider. a) When you think in library files that can be linked to your application you get the risk of restrict the capabilities of your own program. Let me try to explain :) We all know that a library file is fixed. So far, the object code cannot be, in general, modifiable. (Except for one or two tools called obj2asm that you are supposed to be able to retrieve back the contents of a given .obj to asm code.) If you build your library files (.obj or .lib) on C or C++, and wants to link it with an common assembler, this is not - generally speaking - a good idea. This is not a good way to go, because when you are dealing with those object files produced by a C/C++ compiler you don´t have access to the internal data, i mean, you can´t modify the code as needed (if it is needed). So if, for some reason the library file is bloated, you will disseminate bloated code all over the other apps from whom you were linking your object file. It get worst when you don´t have the C or C++ source...imagine that you got the object file from a friend, or somehow you don´t have the source code. All you have is the object file. Again, if the obj file have bloated code, you are doomed to use it as it is, like it or not. It could be an good idea importing and linking object files that where produced by C or C++ for example, except for the fact that you are restricted to use them and not _modify/fix_ them. Also, if you want let´s say to use on your C/C++ app a library made with Delphi, for example, or with any other object file that is OMF (and not Coff), you can´t use it, unless you convert the OMF to Coff with another tool. (And yet..you don´t have access to the internal data as well) So, the reason why linking _for me_ is not a good idea is basically because you can´t fix the object code, and you can´t use the source code (specially, if it came from C or C+ sources..i mean...when you don´t have the asm source). b) However, exporting an object file (.lib or .obj from an asm source) to be used in your other C/C++ applications could be usefull because since you wrote them in assembly, it means that you have more control of the code and, by consequence, the quality of the data stored inside the object file. - Again...assuming you have the source code in asm. The only question here is..Why ? If you are building your app in assembly, why would you want that the object code produced by it, should be used or linked on a C or C++ compiler ? You may argue: well....Sometimes i want a routine or library built in asm on my C/C++ projects....Well..if is that it...so, use inline assembly, it is way better when you are used to your compiler syntaxes, and don´t have to learn how to use another asembler just to produce an object code, when you own compiler can do that with the routines you built inline. One reason that it can be usefull is portability to other assemblers. For example i have a object code produced in masm, and want to use this on my fasm project (I don´t know if fasm allow linking, but..i guess you got the idea). But..again..this is only usefull..assuming you have the source code that produced that object file, so if something is wrong, you can modify it with your assembler, and fix the object code to be used in another assembler. So, in both cases (Importing and exporting) it is better that you have the source code or some representation of it. What we are currently doing with the LibScanner can also be used to solve those situations, even when you don[t have the source. It is primarilly designed for a tool we are working with called DIS System to be used with the disassembler as we already told here many times...But also, it can be used to you translate the source inside a given object file, and fix it !!!.....Not that it will produce any object code for now...it will produce the source code to you use/modify/fix it. So, if you have a C or C++ object code (Coff for now, but later...Delphi, or Borland OMF, DCU, CVL libraries), you don´t need a linker. All you need is the source code. When you suceeded to retrieve/translate the source code, all you need to do is store it on the clip features, for example. This is what the clip feature is for. You can save your functions to be reused later with other apps you want to build. Best Regards, Guga
From: Guga on 19 Sep 2005 23:49
Oops CVL Libraries ? Sorry.. I mistyped (Coff for now, but later...Delphi, or Borland OMF, DCU, VCL libraries), Guga |