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