search

michaelcmartin / Ophis

A cross-assembler for the 6502 series of microprocessors.
http://michaelcmartin.github.io/Ophis/
Other
96 stars 26 forks source link

Have .incbin take an optional offset and length for source bytes. #3

Closed catseye closed 12 years ago

catseye commented 12 years ago

This change extends the syntax of .incbin to be:

.incbin "FILENAME"[, OFFSET[, LENGTH]]

where OFFSET and LENGTH are literal numbers. The bytes to be included are read from the file starting at the OFFSET, and at most LENGTH bytes are included.

The main practical use of this would be for including binary data from some file format which includes headers, when you don't want to include the headers in your binary. As a specific example, Commodre 64 sprites saved as .PRG files include a two-byte load address before the actual data. To include only the sprite data, you could say .incbin "sprites.prg", 2. (The use case for the length is admittedly a little less well-motivated, but consistency seems to call for it. It could be useful to trim out junk from files padded to certain multiples of a chunk size, perhaps.)

I'm certainly not married to this specific syntax, and would be open any suggestions for a better one.

If you think this is something you'd like to see in Ophis, I can think of a few ways to improve it: I could figure out how to use parse_expr and use it to allow arbitrary Ophis expressions for OFFSET and LENGTH; and I could add a test case under tests/ for .include and the various forms of .incbin.

michaelcmartin commented 12 years ago

I like the idea of parse_expr for those, and I agree that there's a place for it. If you want to develop it further before pulling it, I'm fine with that too.

catseye commented 12 years ago

Sure, I'd like to flesh this out a bit. Watch this space...

michaelcmartin commented 12 years ago

I've been on an extremely dedicated development kick on Ophis, and much of the code has been heavily reformatted. Working on issue #12 has also demonstrated that making this parse_expr-aware is going to involve some more thorough changes to the intermediate representation if it's going to be worth the effort.

I'm not jumping on this immediately - I've got several other things I want to get in still - but unless you have some major expansions for me to review and incorporate, it's probably best if I simply take the issue over myself,

catseye commented 12 years ago

Sure, go right ahead. I haven't had much time to do much development at all lately, so I probably wouldn't be able to get to it in a while anyway.