Hi Ian, Here at last is a dump of the unix related files that provide the faster bitblt for the Pi and any other interested platform. Although a lot of the work was specialised for ARM machines there is a fair bit that is completely generic and should (I emphasize the 'should') work on any machine since it is plain C code. There is another chunk that is about to go into Cross, which seems the best place at least to start us off.
Hopefully the attached zip will transfer correctly, though given how tediously annoying it was to assemble I would be surprised. The xarchive tool provided in Raspbian is, to be polite, pathetic. I eventually gave up and used the zip tool in Squeak; it may be best to use that to extract the files since I noticed that at least on my iMac the existence of two files named config.cmake caused problems.
What we have here is - vm/sqPlatformSpecific.h with a #define added - this is clearly not a really good solution and if you know how to make it practical to cause cmake to allow configure with or without -DENABLE_FAST_BLT whilst not messing up the assorted CFLAGS I'd be very pleased. - plugins/BitBltPlugin/config.cmake a new file in a new directory. This *seems* to work correctly on non-ARM machines but I am unable to guarantee it is the right way to do things. I didn't write it, so feel free to excoriate it. - vm-display-x11/ config.cmake (see previous) sqUnixX11Arm.s - assembler code for a faster routine for converting the pixel format sqUnixX11.c - modified old file to use above faster display handler. I added archive comments to the file to hopefully help sort out which config is which. If I can send you the files in some more convenient manner just let me know.
The value of this on the Pi is pretty high, with some cases being 10x faster; I'll be interested to know if it does any good on other machines. Someone may find it interesting to do the x86 assembler as an experiment, though I'd be surprised if it made as much difference on a fast large memory bus as on a slow narrow one.
cc'd to the rest of the gang in case anyone wants to play with it right now.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: ESBD: Erase System and Burn Documentation
OK, the commit of the Cross code seems to have worked. It should now be possible to load the latest plain-interp VMMaker svn update generate sources build get a working vm
On non-ARM unix machines you might try editing the vm/sqPlatformSpecific.h file to allow ENABLE_FAST_BLT anyway - it ought to work and provide some improvement for some cases. Take a look at files in Cross/plugins/BitBltPlugin like BitBltGeneric and BitBltDispatch.
I think we've been able to show that it won't break anything for non-ARM/non-linux machines but no guarantee is made until we've collectively tested it.
In case you want to skip the generate source part, here is a ready made BitBltPlugin.c file ready to go into platforms/unix/src/vm/intplugins/BitBltPlugin
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- On permanent leave of absence from his senses.
And of course, the subject line ought to be uniX code for new faster bitblt….
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Computer and car salesmen differ in that the latter know when they are lying.
Wow, as much as 10x? As soon as I can get time I'll try this out on both my Mac and my Pi with a few different images. I bet Cuis breaks the sound barrier:)
On Tue, Jun 18, 2013 at 5:19 PM, tim Rowledge tim@rowledge.org wrote:
And of course, the subject line ought to be uniX code for new faster bitblt….
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Computer and car salesmen differ in that the latter know when they are lying.
On 18-06-2013, at 7:14 PM, Casey Ransberger casey.obrien.r@gmail.com wrote:
Wow, as much as 10x? As soon as I can get time I'll try this out on both my Mac and my Pi with a few different images. I bet Cuis breaks the sound barrier:)
It'll vary enormously; certainly no 10x for x86 machines I think. On Raspbian Pi some cases are 10x, many are 5x but a few are actually slower. The key thing is that there is a decently intelligible framework into which more special case can be bult as needed and available. I suspect the code to search for a matching fast path might be improvable too, which will speed up the important small area blts.
And of course, a lot of drawing really ought to be via vector code anyway.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Implementation is the sincerest form of flattery.
Sigh. There always has to be some fly in your nice new ointment, doesn't there?
I've been trying to make the faster blt for the StackVM and having a rather unpleasant time trying to make any sense of auto* (but then it seems that is standard). The *really* annoying thing I've just discovered/realised is that we will need to get the assembler sources re-worked by the author in order to work with the standard 'gas' assembler, rather than relying on having asasm installed. I had no idea that source would be incompatible…
So, in the plain interpreter there is no current practical problem since the cmake fragments are set up to see if you are building on an ARM, which isn't completely satisfactory but decently 'safe'. And anyway, Ian hasn't added them to the SVN yet.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Calls people to ask them their phone number.
Is it minor variance in syntax or are we talking the difference between at&t and intel assembler? How much assembly code is there? I wasn't able to find anything on this asasm, can you point me at something?
On Mon, Jun 24, 2013 at 5:01 PM, tim Rowledge tim@rowledge.org wrote:
Sigh. There always has to be some fly in your nice new ointment, doesn't there?
I've been trying to make the faster blt for the StackVM and having a rather unpleasant time trying to make any sense of auto* (but then it seems that is standard). The *really* annoying thing I've just discovered/realised is that we will need to get the assembler sources re-worked by the author in order to work with the standard 'gas' assembler, rather than relying on having asasm installed. I had no idea that source would be incompatible…
So, in the plain interpreter there is no current practical problem since the cmake fragments are set up to see if you are building on an ARM, which isn't completely satisfactory but decently 'safe'. And anyway, Ian hasn't added them to the SVN yet.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Calls people to ask them their phone number.
On 24-06-2013, at 5:53 PM, Casey Ransberger casey.obrien.r@gmail.com wrote:
Is it minor variance in syntax or are we talking the difference between at&t and intel assembler? How much assembly code is there? I wasn't able to find anything on this asasm, can you point me at something?
It turns out (I had no idea that it even existed, I've never made use of the root project) that it is part of the gcc-for-RISC OS project. There is a linux version (obviously, or I wouldn't have had the problem) which I was given along with the blt sources.
With no experience in using `gas` I can't really even guess at what the differences might be, though at least the actual instructions must surely be the same! Although, given the way of the world, maybe not. For an example, here is the asm file for the x11 helper routine, written for the same asasm tool
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Oxymorons: Sweet sorrow
Ouch. Okay we *are* in fact looking at the difference between Intel (asasm) and AT&T (gas [also, yuck]) syntax.
If there isn't that much asm code, we can translate it by hand. If there's a whole lot of it, maybe it would be more productive to try to parse out the AST and then pretty print it out to AT&T syntax. Macros might make that really hard, though.
On Mon, Jun 24, 2013 at 6:03 PM, tim Rowledge tim@rowledge.org wrote:
On 24-06-2013, at 5:53 PM, Casey Ransberger casey.obrien.r@gmail.com wrote:
Is it minor variance in syntax or are we talking the difference between
at&t and intel assembler? How much assembly code is there? I wasn't able to find anything on this asasm, can you point me at something?
It turns out (I had no idea that it even existed, I've never made use of the root project) that it is part of the gcc-for-RISC OS project. There is a linux version (obviously, or I wouldn't have had the problem) which I was given along with the blt sources.
With no experience in using `gas` I can't really even guess at what the differences might be, though at least the actual instructions must surely be the same! Although, given the way of the world, maybe not. For an example, here is the asm file for the x11 helper routine, written for the same asasm tool
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Oxymorons: Sweet sorrow
On 24-06-2013, at 6:13 PM, Casey Ransberger casey.obrien.r@gmail.com wrote:
Ouch. Okay we *are* in fact looking at the difference between Intel (asasm) and AT&T (gas [also, yuck]) syntax.
If there isn't that much asm code, we can translate it by hand. If there's a whole lot of it, maybe it would be more productive to try to parse out the AST and then pretty print it out to AT&T syntax. Macros might make that really hard, though.
Yah. That's why we're probably best off waiting for Ben to be free again. There's a *lot* of ASM code. At least he already knows what it all is supposed to do. Unless, of course, it is in fact work done by a spirit guide that controlled his typing whilst under the influence of exotic medications.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Not enough sense to come in out of the rain.
Hi:
On 25 Jun 2013, at 03:23, tim Rowledge tim@rowledge.org wrote:
On 24-06-2013, at 6:13 PM, Casey Ransberger casey.obrien.r@gmail.com wrote:
Ouch. Okay we *are* in fact looking at the difference between Intel (asasm) and AT&T (gas [also, yuck]) syntax.
If there isn't that much asm code, we can translate it by hand. If there's a whole lot of it, maybe it would be more productive to try to parse out the AST and then pretty print it out to AT&T syntax. Macros might make that really hard, though.
Yah. That's why we're probably best off waiting for Ben to be free again. There's a *lot* of ASM code. At least he already knows what it all is supposed to do. Unless, of course, it is in fact work done by a spirit guide that controlled his typing whilst under the influence of exotic medications.
How about just decompiling the binary (i.e. the compiled ASM code) to the proper format?
Best regards Stefan
On 25-06-2013, at 1:02 AM, Stefan Marr smalltalk@stefan-marr.de wrote:
How about just decompiling the binary (i.e. the compiled ASM code) to the proper format?
if you know a way to do that and get readable, maintainable code at the end, do please let us know. That would be a seriously useful trick!
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- If you give him a penny for his thoughts, you get change back.
On Jun 25, 2013, at 9:38 AM, tim Rowledge tim@rowledge.org wrote:
On 25-06-2013, at 1:02 AM, Stefan Marr smalltalk@stefan-marr.de wrote:
How about just decompiling the binary (i.e. the compiled ASM code) to the proper format?
if you know a way to do that and get readable, maintainable code at the end, do please let us know. That would be a seriously useful trick!
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- If you give him a penny for his thoughts, you get change back.
Wait. I thought we were talking about assembly language! :P
On 25-06-2013, at 3:02 PM, Casey Ransberger casey.obrien.r@gmail.com wrote:
On Jun 25, 2013, at 9:38 AM, tim Rowledge tim@rowledge.org wrote:
On 25-06-2013, at 1:02 AM, Stefan Marr smalltalk@stefan-marr.de wrote:
How about just decompiling the binary (i.e. the compiled ASM code) to the proper format?
if you know a way to do that and get readable, maintainable code at the end, do please let us know. That would be a seriously useful trick!
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- If you give him a penny for his thoughts, you get change back.
Wait. I thought we were talking about assembly language! :P
Ooh, snap. It *is* just about possible to write clear, maintainable assembler code, just like it is in theory possible to write a clear, intelligible tax code.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: ESC: Emulate Small Child
On Jun 25, 2013, at 3:17 PM, tim Rowledge tim@rowledge.org wrote:
On 25-06-2013, at 1:02 AM, Stefan Marr smalltalk@stefan-marr.de wrote:
How about just decompiling the binary (i.e. the compiled ASM code) to the proper format?
if you know a way to do that and get readable, maintainable code at the end, do please let us know. That would be a seriously useful trick!
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- If you give him a penny for his thoughts, you get change back.
Wait. I thought we were talking about assembly language! :P
Ooh, snap. It *is* just about possible to write clear, maintainable assembler code, just like it is in theory possible to write a clear, intelligible tax code.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: ESC: Emulate Small Child
The main problem in my view with both systems: they predate garbage collection. If the tax codes ever threw anything out, we wouldn't be in this mess:)
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?
I'm more familiar with Intel syntax myself but I do enjoy a spot of assembler once in awhile. AT&T syntax is yucky and kind of scary, but it's just syntax and that's not too bad.
I have a Pi and I've been looking for some way to contribute around that. Maybe I can help with this and learn about the Pi's graphics facilities while I'm at it. That could be fun.
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/...
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Computing Dictionary: LOOP: (go to LOOP)
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/...
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
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/...
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
Also, this too: http://code.google.com/p/ta2as/
On Wed, Jun 26, 2013 at 9:01 PM, Casey Ransberger casey.obrien.r@gmail.comwrote:
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.comwrote:
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/...
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
On 26-06-2013, at 9:21 PM, Casey Ransberger casey.obrien.r@gmail.com wrote:
Also, this too: http://code.google.com/p/ta2as/
On Wed, Jun 26, 2013 at 9:01 PM, Casey Ransberger casey.obrien.r@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
Interesting. Another possibility we've been discussing would add the source for asasm to the squeak SVN tree and add rules to make it at need. It's GPL licensed, which might or might not be a problem; I'm sure somebody will have opinions.
On a related issue, I finally made enough sense of cmake to spot a way to get the relevant define, err, defined, without having to alter the sqPlatformSpecific.h, which is a nice improvement. I'm still inclined to think that some manner must exist to only try to compile the related C files if you want them, rather than relying on the library linking to dump unwanted code.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Base 8 is just like base 10, if you are missing two fingers.
Hi,
as I was just skimming some source (SML/NJ) I found a header file assyntax.h that abstracts ASM from the underlying assembler, be it AT&T, gas, or Apple as. It apparently comes from Mesa, see here: http://cgit.freedesktop.org/mesa/mesa/tree/src/mesa/x86/assyntax.h
Hope this helps
Best -Tobias
On 26-06-2013, at 9:35 PM, tim Rowledge tim@rowledge.org wrote:
On a related issue, I finally made enough sense of cmake to spot a way to get the relevant define, err, defined, without having to alter the sqPlatformSpecific.h, which is a nice improvement. I'm still inclined to think that some manner must exist to only try to compile the related C files if you want them, rather than relying on the library linking to dump unwanted code.
The pile'o'filesfor this is available for any heroic person to try out on an intel machine; I'd be fascinated to hear if it makes any difference when you already have a huge cache and wide memory bus to cover up mild inefficiencies.
https://www.dropbox.com/s/kq2jlfwxo4c1n1g/BenBLT-unix.zip
A normal ../../cmake/configure should build a perfectly ordinary interpreter vm. ../cmake/configure --enableFastBlt should make the fast blt, and (I hope) should appropriately skip the ARM specific stuff. I'm pretty sure that some extra IF clause in the plugins/BitBltPlugin/config.cmake script would be useful for skipping the BitBltDispatch & BitBltGeneric files when un-needed but damned if I can work out how right now.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: HCF: Halt and Catch Fire
Hi Tim,
I'm trying to integrate your code and I have some doubts (very simple ones, as you will see :).
So far, I integrate your code into CogVM and StackVM by enabling ENABLE_FAST_BLT and adding BitBltGeneric.c, BitBltDispatch.c into the code base. (btw, it compiles, but I really don't know if something is missing and how to measure the enhancement).
Now, I want to extend the code to the iOS vm's (for example, for DrGeo2 would be great), and since iOS is a FreeBSD over an ARM, I do not see why it should not work more or less out of the box :)
And well... my doubt is which files should I include, since there are various there :)
(btw.. since they are not really "cross", shouldn't them be in other(s) platform directories?)
Thanks, Esteban
On Jun 29, 2013, at 3:44 AM, tim Rowledge tim@rowledge.org wrote:
On 26-06-2013, at 9:35 PM, tim Rowledge tim@rowledge.org wrote:
On a related issue, I finally made enough sense of cmake to spot a way to get the relevant define, err, defined, without having to alter the sqPlatformSpecific.h, which is a nice improvement. I'm still inclined to think that some manner must exist to only try to compile the related C files if you want them, rather than relying on the library linking to dump unwanted code.
The pile'o'filesfor this is available for any heroic person to try out on an intel machine; I'd be fascinated to hear if it makes any difference when you already have a huge cache and wide memory bus to cover up mild inefficiencies.
https://www.dropbox.com/s/kq2jlfwxo4c1n1g/BenBLT-unix.zip
A normal ../../cmake/configure should build a perfectly ordinary interpreter vm. ../cmake/configure --enableFastBlt should make the fast blt, and (I hope) should appropriately skip the ARM specific stuff. I'm pretty sure that some extra IF clause in the plugins/BitBltPlugin/config.cmake script would be useful for skipping the BitBltDispatch & BitBltGeneric files when un-needed but damned if I can work out how right now.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: HCF: Halt and Catch Fire
On 17-07-2013, at 6:36 AM, Esteban Lorenzano estebanlm@gmail.com wrote:
Hi Tim,
I'm trying to integrate your code and I have some doubts (very simple ones, as you will see :).
Excellent; Eliot & I were just trying to do some of this on Monday. Clearly we should try to get together.
So far, I integrate your code into CogVM and StackVM by enabling ENABLE_FAST_BLT and adding BitBltGeneric.c, BitBltDispatch.c into the code base. (btw, it compiles, but I really don't know if something is missing and how to measure the enhancement).
For non-ARM platforms I have no idea whether there will be any benefit to using ENABLE_FAST_BLT. I rather suspect that modern desktop & laptop machines have such large caches and such wide memory busses that there isn't any meaningful bottleneck to work around; by contrast the Raspberry Pi has a narrow and slow memory bus and a whole, massive, amazing 32kb or so of cache. Pre-fetching cachelines whilst doing other stuff can pay off handsomely.
BitBltGeneric and BitBltDispatch are generic (duh) C files that ought to work ok on any machine. They really ought to be compiled only when the fastblt is enabled during running configure. They shouldn't cause a problem even if compiled since the linking/library phase should just drop everything. Do all library/linking programs do it perfectly? Only in Harry Potter and the Perfect Linker.
BitBltArm.c ought not be used unless the target cpu is an ARM. BitBltArmLinux.c is for linux /arm machines, to discover exactly which version of an ARM it is at runtime. BitBltArmOther.c is a stub for non-linux systems; fill it out as needed.
The .s files need to be assembled with 'asasm' NOT gas. There is certainly an argument for converting them to be gas compatible but the original author ain't interested. He prefers the cleaner syntax and better macros and other reasons. asasm is open source and available so it shouldn't be any more of a problem than the fact that you need to load cmake for the plain interpreter or autoconf for cog.
Now, I want to extend the code to the iOS vm's (for example, for DrGeo2 would be great), and since iOS is a FreeBSD over an ARM, I do not see why it should not work more or less out of the box :)
Except for needing to get asasm, it should be no problem. You may need to do some fiddling to replicate the detectCpuFeatures() function.
And well... my doubt is which files should I include, since there are various there :)
You'll need all of them except BitBltArmLinux & BitBltArmOther, plus you'll need to write BitBltArmIOS.c And if you get really ambitious you might want to add still more special cases. And it really seems likely to me that some large chunk of the marshalling of parameters for the bitblt could be done better and faster; for small area bitblts I suspect that overwhelms the time taken to move bits around.
(btw.. since they are not really "cross", shouldn't them be in other(s) platform directories?)
It's a tricky one. We don't have any clean way to handle cpu diferentiation in the tree.
What *might* be a good idea would be to have a Cross/plugins/FastARMBitBltPlugin directory and make things work such that it is used instead of the plain bitblt code when configured.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Objects are closer than they appear.
On 17-07-2013, at 9:54 AM, tim Rowledge tim@rowledge.org wrote:
On 17-07-2013, at 6:36 AM, Esteban Lorenzano estebanlm@gmail.com wrote:
Hi Tim,
I'm trying to integrate your code and I have some doubts (very simple ones, as you will see :).
Did you make any progress on this? Any interesting problems to report?
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- One too many lights out in his Christmas tree.
Hi tim
From what I know esteban went on holiday for a week. I do not expect him to work during VM during this time.
Stef
Hi Tim,
I'm trying to integrate your code and I have some doubts (very simple ones, as you will see :).
Did you make any progress on this? Any interesting problems to report?
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- One too many lights out in his Christmas tree.
On 22-07-2013, at 10:39 AM, stephane ducasse stephane.ducasse@gmail.com wrote:
Hi tim
From what I know esteban went on holiday for a week. I do not expect him to work during VM during this time.
Holiday? Is that allowed?
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: WAF: Warn After the Fact
Hi tim
From what I know esteban went on holiday for a week. I do not expect him to work during VM during this time.
Holiday? Is that allowed?
;) Somehow
and important. I'm on holidays and normally I should not read mails :) and write books and code. Highly forbidden practices :)
Stef
Hi Tim,
As Stef said, I was on holidays. Well... the work of integration faster BitBlt is just started. I'm using now the "platform independent" sources, but still didn't have the time to start integrate the specific ARM ones... I will, but just in the next weeks :)
cheers, Esteban
On Jul 22, 2013, at 9:40 PM, stephane ducasse stephane.ducasse@gmail.com wrote:
Hi tim
From what I know esteban went on holiday for a week. I do not expect him to work during VM during this time.
Holiday? Is that allowed?
;) Somehow
and important. I'm on holidays and normally I should not read mails :) and write books and code. Highly forbidden practices :)
Stef
On 29-07-2013, at 10:58 PM, Esteban Lorenzano estebanlm@gmail.com wrote:
Hi Tim,
As Stef said, I was on holidays.
Hope it was fun and restful.
Well... the work of integration faster BitBlt is just started. I'm using now the "platform independent" sources, but still didn't have the time to start integrate the specific ARM ones... I will, but just in the next weeks :)
Keep in touch as you go; I hope you're knowledgeable about all the nasty autoconf stuff. Or does the iOS setup not use that?
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim USER ERROR: replace user and press any key to continue.
On 30 July 2013 18:11, tim Rowledge tim@rowledge.org wrote:
On 29-07-2013, at 10:58 PM, Esteban Lorenzano estebanlm@gmail.com wrote:
Hi Tim,
As Stef said, I was on holidays.
Hope it was fun and restful.
Well... the work of integration faster BitBlt is just started. I'm using now the "platform independent" sources, but still didn't have the time to start integrate the specific ARM ones... I will, but just in the next weeks :)
Keep in touch as you go; I hope you're knowledgeable about all the nasty autoconf stuff. Or does the iOS setup not use that?
we using cmake stuff. :)
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim USER ERROR: replace user and press any key to continue.
On 24.06.2013, at 17:01, tim Rowledge tim@rowledge.org wrote:
we will need to get the assembler sources re-worked by the author in order to work with the standard 'gas' assembler, rather than relying on having asasm installed.
This thread seems to indicate that asasm can be made to work on Linux:
http://list-archives.org/2013/03/11/gcc-gccsdk-riscos-info/gccsdk-porting-as...
- Bert -
On 25-06-2013, at 10:12 AM, Bert Freudenberg bert@freudenbergs.de wrote:
On 24.06.2013, at 17:01, tim Rowledge tim@rowledge.org wrote:
we will need to get the assembler sources re-worked by the author in order to work with the standard 'gas' assembler, rather than relying on having asasm installed.
This thread seems to indicate that asasm can be made to work on Linux:
http://list-archives.org/2013/03/11/gcc-gccsdk-riscos-info/gccsdk-porting-as...
Oh, absolutely it can, or I wouldn't have been able to make the plain interp with the benblt code. The practical problem is that it doesn't (seem to) play nicely with the gcc idiom of telling the system which assembler to use and letting it call said asm for you. The args don't match, so far as I can tell, but perhaps there is a rune to fix that. The other issue is that requiring the installation of an ARM specific tool when one isn't really needed is a bit unfriendly.
A side issue is that the cmake config stuff almost certainly needs some better testing for whether you want to and are able to use the fast blt code. Anyone with cmake knowledge that cares to offer assistance would be most welcome.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim To succeed in politics, it is often necessary to rise above your principles.
vm-dev@lists.squeakfoundation.org
-
Bert Freudenberg -
Casey Ransberger -
David T. Lewis -
Esteban Lorenzano -
Igor Stasenko -
Stefan Marr -
stephane ducasse -
tim Rowledge -
Tobias Pape