[Vm-dev] unit code for new faster bitblt
casey.obrien.r at gmail.com
Thu Jun 27 04:21:07 UTC 2013
Also, this too: http://code.google.com/p/ta2as/
On Wed, Jun 26, 2013 at 9:01 PM, Casey Ransberger
<casey.obrien.r at gmail.com>wrote:
> Hello folks. I was riding on a surfboard when I jumped over this little
> shark, which seems perchance at least useful as food for thought. It
> purportedly converts MASM (which uses an Intel-style syntax) to the AT&T
> style. It might just work, though more likely we'd have to tweak it to
> understand various idiosyncrasies of ASASM.
> I was somewhat surprised by how short the script is; it's certainly much
> smaller than the amount of assembler code, which suggests that
> automatically converting it may be a viable solution after all, and we'd
> avoid both losing signal to a disassembler, as well as the work of a manual
> translation. I'd been thinking of tackling it with OMeta/JS if I didn't
> find anything else to use, but then I saw this:
> On Tue, Jun 25, 2013 at 7:47 PM, David T. Lewis <lewis at mail.msen.com>wrote:
>> On Tue, Jun 25, 2013 at 04:44:02PM -0700, tim Rowledge wrote:
>> > On 25-06-2013, at 4:38 PM, Casey Ransberger <casey.obrien.r at gmail.com>
>> > >
>> > > Okay, just so I'm not burning all my bandwidth on snark here, is
>> there a repo where I can look at all the code?
>> Speaking of which, although perhaps a bit off topic, I notice that there
>> are some issues in the Cross/plugins/BitBltPlugin code that are flagged as
>> compiler warnings when compiled on a 64-bit Linux platform. I can't offer
>> a fix, but I want to make you aware of them. The problems are related to
>> storing pointers into variables declared as uint32_t, which does not work
>> if pointers do not happen to be 32 bits long.
>> The problem areas are within some CPP macros, so it's hard for me to
>> them exactly. But here are some suspicious code snippets (edited for
>> uint32_t halftone = 0;
>> uint32_t *halftoneBase = (uint32_t *) *op->halftoneBase;
>> halftone = (halftoneBase + halftoneHeight);
>> So I expect that the halftone variable needs to be a pointer rather than
>> a uint32, and it looks like these pointers are later passed as function
>> parameters through CPP macros, and whatever they get passed to also need
>> to have the parameters declared as pointers rather than unit32 values.
>> Maybe you can pass this along to Ben, who will no doubt be able to make
>> better sense of it. None of this will affect a 32-bit platform, but it
>> will segfault on a 64-bit platform for sure.
> Casey Ransberger
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Vm-dev