[Vm-dev] unit code for new faster bitblt

[Casey Ransberger]

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



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