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