Was sizeof(char) really 2, or was it just that char was 16 bits? Either way, I'm pretty sure that was a C54x thing. That doesn't apply to the C64+ DSP on DaVinci, that much I can tell you.
People have been running various forms of Linux on our DSPs and ARMs prior to this. I think the real news is that TI's embracing it this time rather than saying "Ok, do as you will" and otherwise ignoring them.
As long as you understand fixed-point arithmetic, it's not too bad to code from C either. I do recommend that you restrict-qualify pointers whenever possible and use some of the #pragma directives to let the compiler know about things like "I know this pointer is aligned to an 8-byte boundary" or "I know this loop goes around eleventy-billion times." Other compilers also benefit from this information, but given the extreme amounts of explicit parallelism and SIMD a DSP like the C64+ offers (up to 8 instructions per cycle, but more like 26 or more actual "operations"), you have much more to gain in DSP-space by giving the compiler this info. DSPs can't spend the transistors desktop CPUs do on dynamically scheduling all those operations at run-time.
Coding for the DSP is actually a lot like coding for MMX or SSE in some ways. (More like MMX when coding for C64x, since the DSPs are fixed point.) Just keep your data types sized appropriately, and in the case of TI DSPs, listen to the feedback from the compiler.
Our compiler supports exceptions now? I've only ever used our C compiler and the linear assembly optimizer. I haven't really touched our C++ support.
All I can say is when you find bugs, send them in and get a bug number. The compiler team does track bugs, and they can't fix bugs they don't know about.
The IDE (Code Composer Studio) is not handled by the compiler team and I don't know if anyone on the compiler team uses it much, if at all. CCS is maintained in TI Toronto, last I knew. They too track bug reports. Unfortunately, though, they're under greater feature pressure than bug fix pressure. That makes it even more important to file bugs. Otherwise they'll never get the message. I'm probably not the only person who finds it a tad ironic that our integrated development environment is actually built out of parts by a handful of groups, at least a couple of which (TI Toronto, formerly Go DSP and TI Santa Barbara, formerly Spectron) used to be 3rd party companies.:-)
FWIW, I don't really use CCS myself either. These days I barely even use the compiler, though. The last time I used CCS seriously, I filed plenty of bugs against it. Our software tools team continues to evolve and I've seen some changes recently that I think will point CCS in a better direction. Here's hoping! (Since I am a TIer, I'm not sure how much I'm allowed to say, so sorry I haven't given more juicy details.)
Can't tell you much about the ARM side, though I will say the TI compiler tends to get high marks on code density and speed on the ARM. I'm sure you could write your ARM code with GCC. I don't know how the heterogeneous linking process works. Only other thing I know off-hand is that there is no flash. Silicon processes that support flash tend to not support high clock rate, and DaVinci can go real fast.:-) More at DaVinci's website.
Disclaimer: I work for TI and had a hand in the C64+ DSP that it includes, but I'm not a member of the DaVinci product team.
That explains all the hooded men with torches walking in and out of dimly lit meeting rooms at work. (I work there and actually had a hand in DaVinci's DSP.) Wait a minute, that means I have parts of DaVinci's code on my hard drive. *looks around suspiciously* Maybe I'll call in sick today.
Overexposure is not so much about bits of dynamic range as it is clamping the amount of charge stored on any given pixel in the CCD array. At some point, you can't put any more charge in a given pixel's charge bucket without it bleeding to other bins excessively due to tunneling or breakdown effects. That's why you get some weird stripes down images if you point your camera at a bright light.
Depends on the languages own naming conventions, usually I stick to them but I tend to use camcelCase because it looks prettier
Funny, I think naming_with_underscores is prettier personally. I feel like my head's being bounced around whenever I see a variable namedLikeThis.
If I'm programming in an IDE which doesn't indent lines too far I'll probably use tabs because it's easier to fiddle with, but I prefer to use 2 spaces otherwise.
I personally prefer 4 and expand tabs to spaces. I've had to work with too many tab-damaged programs to leave tabs in my source.
"if (cond) {" vs. "if (cond)\n{"
I have to go with "if (cond)\n{" with the brace lined up to the if. It works better with VI's indent operators < and >. Handy tip: Increase the indent level of a block of code by placing the cursor on *either* brace and press >%. Decrease with <%. Handy, huh? Now, what I'm curious about, is how many projects other than maybe Emacs and GCC use the FSF's crazy indentation scheme: (The dots are there to preserve the relative spacing.)
Differently-impressive is the Tree VLIW IBM has come up with. Here's a blurb from the site:
In our VLIW architecture, a program consists of a sequence of tree-instructions, or simply trees, each of which corresponds to an unlimited multiway branch with multiple branch targets and an unlimited set of primitive operations. All operations and branches are independent and executable in parallel. The multiway branch is associated with the internal nodes of the tree, whereas the operations are associated with the arcs.
In other words, each VLIW instruction word isn't just a branch, it's a multiway branch. One tree-VLIW prototype could execute up to 8 branches a cycle.
I wonder if Mel had anything to do with that architecture...
The main place where goto seems to foul up compilers is where it makes the control-flow graph (CFG) something more complicated than the graphs that arise from normal conditional flow. CFGs arising from normal nesting control-flow constructs can be drawn on a 2-D surface with no lines crossing each other. The same can't always be said of code littered with gotos.
--Joe
Re:I failed a coding test because of this guy
on
Goto Leads to Faster Code
·
· Score: 3, Informative
Yeah, that is BS! Especially when you have Donald Knuth, Brian Kernighan and Ken Thompson on record in defense of goto when it's warranted. References: Knuth's "Structured Programming with GOTO" (link appears dead), Kernighan, and Ken Thompson: "If you want to go somewhere, goto is the best way to get there."
Anyway, swinging carefully back on topic, it sounds like Mr. Goto's work is at the instruction level, not the C or Fortran or even really at the algorithmic level (except maybe tricks like tiling). I program in the embedded space, where getting as close to 100% efficiency is a continual challenge. I wonder if any of his techniques scale down...
Our laptops and PCs come pre-hosed as a matter of corporate policy. IT shoves a metric boatload of crap into auto-run, slowing it to a crawl both on boot and in operation. Some of it is reasonably necessary: backup software, antivirus software, firewall software. Some of it is of questionable value. For instance, they run SMS scripts that catalog the last time I accessed each file on my hard drive, what software apps I have installed, when I last ran them, etc. (Yes, they monitor that crap, and it all goes into a big database somewhere.)
Then there's our backup software. <rant> Backups are reasonably necessary, but I'm particularly annoyed with ConnectedTLM. First off, what is it with Windows apps insisting on popping something up to tell you they're doing something? I don't mind a tray icon to tell me a backup is in progress, but why pop up something over my work? Furthermore, why does it literally take 5 minutes to cancel a backup if I miss the little "defer" popup that gave me the option to not interrupt my work at the moment? (Happens like clockwork that I get up for a rest break, come back, and ConnectedTLM is thrashing away my HD.) And finally, what is it with meaningless progress bars? If you've ever seen ConnectedTLM, it'll make its way up to about 70%, and then hover between 68% and 72% forever before suddenly getting to 100%. (Yes, it goes up and down! WTF?)</rant>
I feel better now.:-) I'm getting a new IT-bullcrap-laden laptop soon. Hopefully it'll run my backups and virus scan (which currently weighs in at about 4.5 hours) significantly faster. It has a newer, faster HD, which I hear makes a very big difference. In the meantime, I do my part to prevent it getting ever more craptastic by running Firefox instead of IE, and periodically delousing it with Spybot and related software. It also helps that I don't browse the web with abandon, although some of the adservers on sites linked off Fark seem to leave interesting crap on the HD. (I've had a couple Java "trojans" show up in the browser cache, and I'm pretty sure that's the vector.)
Caches fundamentally reward spatial and temporal locality. Proper data structure and algorithmic design will help you on any modern system. If you want to go back to the bad-old-days of 10MHz and slower machines, we can get rid of the cache. Caches let you go faster and get the GHz rates we're hooked on.
I don't think you should hard-code for a cache size unless your target is very specific. One place where you would code to particular cache sizes and layouts is the embedded space. (I should know, I work there.) Even then, you can do so in a parameterized manner: #define is your friend here.
As for self-examining systems... We have that today, to a certain extent. Look up Intel's VTune. It's hard to see how you'd change a particular data structure's implementation at run time, though, based on such fine-grained detail. That sort of fine detail is best given to the programmer. Really, what you want to do is have a well-known way for CPUs to inform programs of cache sizes so they can size arrays, queues and other scalable structures appropriately as part of the program's initialization. For instance, if you're operating on large matrices and you can tile your accesses to that matrix, you would set your tile size based on the size of your L1D cache. Otherwise you risk having a tile that's too small (to cater to a large number of systems easily, but incurs a larger fraction of loop overhead) or too big (and thus thrashes some systems).
Other neat tricks include using things like space-filling curves (such as Hilbert curves) to define your traversal through large multidimensional arrays. These sorts of curves have the neat property that they localize accesses pretty close to optimally regardless of the cache size. Their downside is that they're not super general. For instance, I don't see how to readily implement a matrix multiply by traversing the matrix in Hilbert-space order. Large image filters though, sure.
EAX vs. AX isn't usually the problem, since references to AX can be understood as references to EAX. The real hiccups come when you use AH and AL relative to either AX or EAX, since you can have a mixture of reads and writes to portions of AX/EAX. I'm pretty sure this is why there's no way to address the upper half of EAX while ignoring the lower half.
Fair enough. But, if, say, your browser history includes a couple pages describing ANFO bombs indicating those pages were viewed a few days before a major ANFO bomb goes off, and the police already suspect you for other reasons, I think this could be seen as effective supporting evidence.
It's not like the only evidence they have is the Google search history, or that that's how they identified their suspect. Rather, the Google search history of a suspect supports everything else they've been building in this case. Timing, cause of death and method of disposal all line up rather well between the search history and what happened IRL.
I mean, if you looked up the Anarchist's Cookbook, or lock picking, or anything else, that's fine and no one's likely to come after you. If, though, you're suspected of some act, and they find additional evidence you were researching it, that only helps the case against you.
Slashdot Mirror
Nah... the DSP on there is a C64+. Maybe our next DSP will be the C68x-family... ;-)
(And no, I wasn't the only one who chuckled when we brought out the C64 DSP family...)
Was sizeof(char) really 2, or was it just that char was 16 bits? Either way, I'm pretty sure that was a C54x thing. That doesn't apply to the C64+ DSP on DaVinci, that much I can tell you.
People have been running various forms of Linux on our DSPs and ARMs prior to this. I think the real news is that TI's embracing it this time rather than saying "Ok, do as you will" and otherwise ignoring them.
--Joe
As long as you understand fixed-point arithmetic, it's not too bad to code from C either. I do recommend that you restrict-qualify pointers whenever possible and use some of the #pragma directives to let the compiler know about things like "I know this pointer is aligned to an 8-byte boundary" or "I know this loop goes around eleventy-billion times." Other compilers also benefit from this information, but given the extreme amounts of explicit parallelism and SIMD a DSP like the C64+ offers (up to 8 instructions per cycle, but more like 26 or more actual "operations"), you have much more to gain in DSP-space by giving the compiler this info. DSPs can't spend the transistors desktop CPUs do on dynamically scheduling all those operations at run-time.
Coding for the DSP is actually a lot like coding for MMX or SSE in some ways. (More like MMX when coding for C64x, since the DSPs are fixed point.) Just keep your data types sized appropriately, and in the case of TI DSPs, listen to the feedback from the compiler.
--Joe
Our compiler supports exceptions now? I've only ever used our C compiler and the linear assembly optimizer. I haven't really touched our C++ support.
:-)
All I can say is when you find bugs, send them in and get a bug number. The compiler team does track bugs, and they can't fix bugs they don't know about.
The IDE (Code Composer Studio) is not handled by the compiler team and I don't know if anyone on the compiler team uses it much, if at all. CCS is maintained in TI Toronto, last I knew. They too track bug reports. Unfortunately, though, they're under greater feature pressure than bug fix pressure. That makes it even more important to file bugs. Otherwise they'll never get the message. I'm probably not the only person who finds it a tad ironic that our integrated development environment is actually built out of parts by a handful of groups, at least a couple of which (TI Toronto, formerly Go DSP and TI Santa Barbara, formerly Spectron) used to be 3rd party companies.
FWIW, I don't really use CCS myself either. These days I barely even use the compiler, though. The last time I used CCS seriously, I filed plenty of bugs against it. Our software tools team continues to evolve and I've seen some changes recently that I think will point CCS in a better direction. Here's hoping! (Since I am a TIer, I'm not sure how much I'm allowed to say, so sorry I haven't given more juicy details.)
--Joe
Can't tell you much about the ARM side, though I will say the TI compiler tends to get high marks on code density and speed on the ARM. I'm sure you could write your ARM code with GCC. I don't know how the heterogeneous linking process works. Only other thing I know off-hand is that there is no flash. Silicon processes that support flash tend to not support high clock rate, and DaVinci can go real fast. :-) More at DaVinci's website.
Disclaimer: I work for TI and had a hand in the C64+ DSP that it includes, but I'm not a member of the DaVinci product team.
That explains all the hooded men with torches walking in and out of dimly lit meeting rooms at work. (I work there and actually had a hand in DaVinci's DSP.) Wait a minute, that means I have parts of DaVinci's code on my hard drive. *looks around suspiciously* Maybe I'll call in sick today.
Overexposure is not so much about bits of dynamic range as it is clamping the amount of charge stored on any given pixel in the CCD array. At some point, you can't put any more charge in a given pixel's charge bucket without it bleeding to other bins excessively due to tunneling or breakdown effects. That's why you get some weird stripes down images if you point your camera at a bright light.
They're probably counting all the #defines, not just the parameterized ones. So crap like "#define DEBUG" probably counts towards the total.
Funny, I think naming_with_underscores is prettier personally. I feel like my head's being bounced around whenever I see a variable namedLikeThis.
I personally prefer 4 and expand tabs to spaces. I've had to work with too many tab-damaged programs to leave tabs in my source.
I have to go with "if (cond)\n{" with the brace lined up to the if. It works better with VI's indent operators < and >. Handy tip: Increase the indent level of a block of code by placing the cursor on *either* brace and press >%. Decrease with <%. Handy, huh? Now, what I'm curious about, is how many projects other than maybe Emacs and GCC use the FSF's crazy indentation scheme: (The dots are there to preserve the relative spacing.)
. if (cond)
. . {
. . . . code...
. . . . code...
. . }
. else
. . {
. . . . code...
. . . . code...
. . }
All those indentation levels make the code look like a giant squiggle. :-)
--JoeWho comes up with these names, anyway?
Ah yes, the story of Mel.
Differently-impressive is the Tree VLIW IBM has come up with. Here's a blurb from the site:
In other words, each VLIW instruction word isn't just a branch, it's a multiway branch. One tree-VLIW prototype could execute up to 8 branches a cycle.
I wonder if Mel had anything to do with that architecture...
--JoeThe main place where goto seems to foul up compilers is where it makes the control-flow graph (CFG) something more complicated than the graphs that arise from normal conditional flow. CFGs arising from normal nesting control-flow constructs can be drawn on a 2-D surface with no lines crossing each other. The same can't always be said of code littered with gotos.
--Joe
Yeah, that is BS! Especially when you have Donald Knuth, Brian Kernighan and Ken Thompson on record in defense of goto when it's warranted. References: Knuth's "Structured Programming with GOTO" (link appears dead), Kernighan, and Ken Thompson: "If you want to go somewhere, goto is the best way to get there."
And then there was the famous "'GOTO Considered Harmful' Considered Harmful" by Frank Rubin, and a a decent section in Steve McConnell's Code Complete that takes an even-handed view.
Anyway, swinging carefully back on topic, it sounds like Mr. Goto's work is at the instruction level, not the C or Fortran or even really at the algorithmic level (except maybe tricks like tiling). I program in the embedded space, where getting as close to 100% efficiency is a continual challenge. I wonder if any of his techniques scale down...
--Joe
Doesn't that terminate a DOS program, returning 0 as the exit code? It's been awhile.
Different obscure machine language: What does this do? 2C 30 C0
--JoeDon't tell Mr Whipple: It looks like someone squeezed the Sharman...
--JoeOur laptops and PCs come pre-hosed as a matter of corporate policy. IT shoves a metric boatload of crap into auto-run, slowing it to a crawl both on boot and in operation. Some of it is reasonably necessary: backup software, antivirus software, firewall software. Some of it is of questionable value. For instance, they run SMS scripts that catalog the last time I accessed each file on my hard drive, what software apps I have installed, when I last ran them, etc. (Yes, they monitor that crap, and it all goes into a big database somewhere.)
:-) I'm getting a new IT-bullcrap-laden laptop soon. Hopefully it'll run my backups and virus scan (which currently weighs in at about 4.5 hours) significantly faster. It has a newer, faster HD, which I hear makes a very big difference. In the meantime, I do my part to prevent it getting ever more craptastic by running Firefox instead of IE, and periodically delousing it with Spybot and related software. It also helps that I don't browse the web with abandon, although some of the adservers on sites linked off Fark seem to leave interesting crap on the HD. (I've had a couple Java "trojans" show up in the browser cache, and I'm pretty sure that's the vector.)
Then there's our backup software. <rant> Backups are reasonably necessary, but I'm particularly annoyed with ConnectedTLM. First off, what is it with Windows apps insisting on popping something up to tell you they're doing something? I don't mind a tray icon to tell me a backup is in progress, but why pop up something over my work? Furthermore, why does it literally take 5 minutes to cancel a backup if I miss the little "defer" popup that gave me the option to not interrupt my work at the moment? (Happens like clockwork that I get up for a rest break, come back, and ConnectedTLM is thrashing away my HD.) And finally, what is it with meaningless progress bars? If you've ever seen ConnectedTLM, it'll make its way up to about 70%, and then hover between 68% and 72% forever before suddenly getting to 100%. (Yes, it goes up and down! WTF?)</rant>
I feel better now.
--Joe
Right, but in the movie, Skynet became sentient on August 29th, 1997.
"Answers, a burden to oneself."
Caches fundamentally reward spatial and temporal locality. Proper data structure and algorithmic design will help you on any modern system. If you want to go back to the bad-old-days of 10MHz and slower machines, we can get rid of the cache. Caches let you go faster and get the GHz rates we're hooked on.
I don't think you should hard-code for a cache size unless your target is very specific. One place where you would code to particular cache sizes and layouts is the embedded space. (I should know, I work there.) Even then, you can do so in a parameterized manner: #define is your friend here.
As for self-examining systems... We have that today, to a certain extent. Look up Intel's VTune. It's hard to see how you'd change a particular data structure's implementation at run time, though, based on such fine-grained detail. That sort of fine detail is best given to the programmer. Really, what you want to do is have a well-known way for CPUs to inform programs of cache sizes so they can size arrays, queues and other scalable structures appropriately as part of the program's initialization. For instance, if you're operating on large matrices and you can tile your accesses to that matrix, you would set your tile size based on the size of your L1D cache. Otherwise you risk having a tile that's too small (to cater to a large number of systems easily, but incurs a larger fraction of loop overhead) or too big (and thus thrashes some systems).
Other neat tricks include using things like space-filling curves (such as Hilbert curves) to define your traversal through large multidimensional arrays. These sorts of curves have the neat property that they localize accesses pretty close to optimally regardless of the cache size. Their downside is that they're not super general. For instance, I don't see how to readily implement a matrix multiply by traversing the matrix in Hilbert-space order. Large image filters though, sure.
--Joe
EAX vs. AX isn't usually the problem, since references to AX can be understood as references to EAX. The real hiccups come when you use AH and AL relative to either AX or EAX, since you can have a mixture of reads and writes to portions of AX/EAX. I'm pretty sure this is why there's no way to address the upper half of EAX while ignoring the lower half.
Fair enough. But, if, say, your browser history includes a couple pages describing ANFO bombs indicating those pages were viewed a few days before a major ANFO bomb goes off, and the police already suspect you for other reasons, I think this could be seen as effective supporting evidence.
It's not like the only evidence they have is the Google search history, or that that's how they identified their suspect. Rather, the Google search history of a suspect supports everything else they've been building in this case. Timing, cause of death and method of disposal all line up rather well between the search history and what happened IRL.
I mean, if you looked up the Anarchist's Cookbook, or lock picking, or anything else, that's fine and no one's likely to come after you. If, though, you're suspected of some act, and they find additional evidence you were researching it, that only helps the case against you.
That's true for object code executables. I don't think it's true for interpreted languages like Perl.
I think Arxan has significant prior art here. They specifically mention obfuscation. I unfortunately can't say much more other than that I've seen some demos of what they offer under NDA. I wish their web site had more meat (e.g. a white paper). I will say they have some bright guys, some of whom come from the NSA, working with them. Heck, even Gene Spafford's on their technical advisory board.
And for the paranoid, I've mentioned nothing above I couldn't find on Arxan's or someone else's public website.
These wacky CS people and their abstract names for things. Why can't they be like perl and call them hashes?
Well, Flash hasn't killed my machine in a very long time. Something about them not making an AMD64 plugin for Linux.