[Vm-dev] unit code for new faster bitblt

Casey Ransberger 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:

http://www.delorie.com/djgpp/mail-archives/djgpp/1995/06/06/05:48:34


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>
> wrote:
> > >
> > > 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?
> >
> >
> >
> http://squeakvm.org/cgi-bin/viewvc.cgi/squeak/trunk/platforms/Cross/plugins/BitBltPlugin/
> >
>
> 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
> brevity):
>
>         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.
>
> Dave
>
>
>


-- 
Casey Ransberger
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20130626/b93384d4/attachment.htm


More information about the Vm-dev mailing list