From: Ullrich von Bassewitz (uz_at_musoftware.de)
Date: 1999-07-10 09:55:24
> mmmh, will there be windoze binaries as well? still no linux here, bah I've created binaries for all supported platforms as usual. > Whatever, i am wondering if the filesupport is still missing in the > libraries... i am working on a real big project atm (music editor with > some never-seen-before features that is) and i would really like to > move the editor crap to C code, since all the pointer and variable shit > is driving me nuts in ASM. well, and obviously there is no sence in an > editor that can't save =) No, there's no low level file support. But then, there's also no low level file support if you write your stuff in assembler, so at least you don't loose anything:-) More seriously: This topic is not quite as easy as it looks on the first glance. It seems that there is no easy way to support files in a standard conform way. One reason is, that you may open a file for reading and writing in C, and this is not possible with the CBM disk drives, at least not with sequential files. The second reason is that things like fseek() must be implemented by closing and reopening the file, then skipping all the bytes from the beginning (things like SEEK_END are even more ugly). This makes the routine almost useless. An alternative would be to use relative files, but these are far more complex to handle, and are not very well supported by many software tools available. In addition, relative files may not be used for some type of data: If you write a program in C that outputs a program file (assembler for example), this program file may not go into a relative file, otherwise it won't be executed by the kernal. So, until I have a good idea how to handle this problem, the easiest way is probably to write a short specialized assembler that reads or writes your data files. If you write your programs in assembler you would also need such a routine, so just make it C callable and use it from the high level code. > however, i dont know what the current version of the compiler looks > like, > but the one i looked at (half a year ago or sth) handled inline assembly > in a quite annoying way (using the asm keyword that is). Well, some people (including me) seem to have a different opinion about what is annoying and what isn't. In fact, the original compiler had a #asm directive that worked the way you described. The reason for replacing it were: 1. #asm is in no way standard conform. C++ specifies an asm() keyword like the one used in cc65. 2. asm() is more flexible, since it allows parametrized assembly instructions similar to what gcc implements. 3. #asm was implemented as a preprocessor directive (like all others starting with #). Since the parser works with a two token lookahead, an absolutely ugly hack was needed to implement #asm (since it is executed by the preprocessor, however, it must be in sync with the parser, so that the emitted code gets in the right place). Apart from that, #asm (and asm()) was never thought to write anything more than two lines of assembly. ca65 is a full featured macro assembler, so why not use it? > another thing is, that i was missing a 'dummy' implementation of > a library function in ASM, that is how to get the params passed to > the routine and how to pass them back. i suppose its like 1st 3 args > are passed in a,x,y and more args on stack... and same thing for > returning them, is that rite ?! Maybe its a good idea to supply a > short example that takes a few args, prints them or sth, and then > returns some other args. Admitted, there is no "dummy" implementation of a C callable assembler function. Instead, there are lots of "real" assembly functions called by the C code with full source code. The lib/ subdirectory contains all sorts of functions that are used in a C program. Examples are strcat(), atol(), isdigit()... Just have a look at the supplied sources. > ok, so far so good... just tell me what you think. Done:-) Regards Uz -- Ullrich von Bassewitz uz_at_musoftware.de ---------------------------------------------------------------------- To unsubscribe from the list send mail to majordomo_at_musoftware.de with the string "unsubscribe cc65" in the body(!) of the mail.
This archive was generated by hypermail 2.1.3 : 2001-12-14 22:05:44 CET