[Vm-dev] unit code for new faster bitblt
casey.obrien.r at gmail.com
Thu Jun 27 04:01:31 UTC 2013
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 locate
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Vm-dev