On Wed, Nov 3, 2010 at 1:48 PM, Marc 'BlackJack' Rintsch <marc@rintsch.de> wrote: > On Wednesday 03 November 2010, Agent Friday wrote: > > Keeping simple things simple is an important principle in software > > design. > > But not to the point of dumbing them down so they can't do the more > complicated stuff. ... I don't in any way mean to suggest that anything be dumbed down, or to let platform-specific stuff creep into the core tool-chain. My working assertion is more like-- "Make the tool flexible enough that you can readily create convenient customizations for any individual platform". cc65 is made that way I think, for the most part. > .word *+2 ; start address > > lda #<hello_txt > ldy #>hello_txt > jsr $ab1e > rts > hello_txt: > .asciiz "HELLO" Hmmm... A simple hack, that prepends what amounts to a "file format" detail to the code. As hacks go, this isn't a huge deal because it's small enough, and once you know the trick it's not too much to swallow. But the implication of this hack in the bigger picture sends chills up and down my spine, and I think it's important enough of an issue to give it some thought. It would be one thing if you could specify the load address of the actual first code byte and specify that the "header" segment be positioned to butt up to it. But having to specify the load address as 2 bytes lower, where nothing will really be loaded, is IMO ugly. The BASIC stub header seems a little less offensive because it's kind of hidden alongside the stub code, which you don't really need to analyze to get what it does. (Or, you THINK you don't need to.) But, in fact, one thing that kept me confused about how the config files actually worked is that the *default* start address for the "RAM" area is specified an $07FF. The actual start of the BASIC RAM area is really $0801, so what is it really trying to do? I had a nagging distrust of those values, and it led me to do nutty things like trying to position things at a +2 offset in that region and try changing the memory area start address(es), etc. to try to get my programs to work. (Of course, that only broke it further....) Only yesterday did I discover what it was really there for after Groepaz directed me to look at crt0.s in the cc65 source. I don't want to go into huge detail in the list at this point, but I think that the load address "header" should perhaps be part of a file format specification. Those 2 bytes should in no way disrupt the correct specification of either a memeory area or where the code segment is actually going to be loaded. I'm not pushing this as something that really needs to happen soon, but if there are those who would like to toss the idea around, I created a wiki page (basically intended to be temporary). That OK Uz? http://wiki.cc65.org/doku.php?id=output_file_format_talk > That "technique" above *is* documented under the headline `Porting > sources from other assemblers <http://www.cc65.org/doc/ca65-17.html>`_ > in the ca65 documentation. Indeed it is. Thanks for pointing it out. Perhaps I missed that because it's mostly explained under the heading "TASS", which I have never used. // Agent Friday ---------------------------------------------------------------------- To unsubscribe from the list send mail to majordomo@musoftware.de with the string "unsubscribe cc65" in the body(!) of the mail.Received on Fri Nov 5 23:17:05 2010
This archive was generated by hypermail 2.1.8 : 2010-11-05 23:17:08 CET