C is pass by value for structures also.
You get pass-by-reference by passing a pointer
to the struct (or whatever you want to pass
by reference). The following code example
illustrates:
Before call: baz.field = 69 After call: baz.field = 69
See? Pass by value, not pass by reference.
ObNit #1: Some ABIs actually define the
calling convention for structs so that structs
are passed by reference. However, if
you read closely, those same ABIs also mandate
that the callee must copy the argument before
writing to it, thereby preserving pass by value
semantics. The advantage is that not all calls
result in a copy, if the callee treats the struct
as read-only.
ObNit #2: C seems like it's pass-by-reference
for arrays, but only because it's impossible to
have an array argument. You can only pass pointers, structs and scalars to functions. (The subtle irony: Structs can contain arrays.) So, when you want to pass an array to a function, you end up really passing a pointer to the array's first element. (An array reference decays to a pointer to the array's first element.)
--Joe
beat a-round the bush
on
Pet Bugs?
·
· Score: 5, Informative
There is no "proper" way to reduce the precision
of a number under all circumstances. Each method of
rounding or truncating 0.5 has its own pitfalls:
Round-to-even, aka. banker's rounding. This is probably the best, since it distributes errors uniformally so as to not cause a long-term average bias. It's also very expensive to calculate as compared to the alternatives.
Round (pseudo)randomly. Add an infintesimally small random or pseudo random bias to numbers that end in 0.5. This has the same
bias properties as round-to-even, but with less
predictability. If the biasing function is just a simple hash of the other bits of the number, though, then at least it's deterministic.
Round-towards-zero. (I believe this is
sometimes called "unbiased rounding".) For numbers uniformally distributed around zero, this form of rounding tends to also have no long-term average bias. The average magnitude is biased, though, towards smaller magnitudes.
Round-towards-plus-infinity. (aka. "rounding
up", or sometimes just "rounding".) This is the rounding
they usually teach you in grade school -- round 0.5 up.
(At least, that's what they taught me until I
got to high-school.)
Round-towards-minus-infinity. (aka. "rounding down" or "truncation".) This is what you get when you always round down. Right-shifting 2s complement numbers (with sign extend) typically
gives you this form of rounding. One nice side effect is that the bias is uniform and so can be made to cancel in some cases elsewhere in your calculation. This technique has the advantage of being the cheapest -- you just throw away bits.
So, as you can see, there's no right way
per se. It just depends on what you're doing.
Yeah, lookup tables are cool. I recently wrote
a Life
implementation for an
old 890kHz CPU. The CPU itself is approximately a 0.1 MIPS device (0.89 MHz, average instruction length
around 8 or 9 cycles).
Even on that slow machine, I had Life running at a
respectable clip. I used one lookup table to
handle packed arithmetic (I did 8 parallel 2-bit
adds in a single 16-bit accumulator), and another
to handle the life/death state transitions. I
used yet another lookup table to map life cells
to pixels on the display (since the display has
a funky encoding).
In the end, I had a 32x24 life field running at about 8 frames per second on that beast. The entire code was about 1K words, and the RAM footprint was tiny too (about 240 bytes for the
life state, 32 words for stack, and
240 words of display memory).
You do have to balance lookup tables against
raw calculation though. Keep in mind also
that lookup tables can lead to local speedups
and global slowdowns. On modern
machines, for example, lookup tables
can thrash out your L1 caches (or in extreme cases,
your L2 cache). Remember that optimization is
a global problem.
For instance, if you're writing a Variable-Length
Code decoder for something like MPEG video decode,
you can't just make a lookup table for the maximum
code length. Well, technically you could, but since the maximum code length is 26 bits,
you'd be in for a 64 mega-entry table. If each table entry is only four bytes, that's 256 megabytes. So obviously, you have to make some
engineering tradeoffs.
My personal rule of thumb is that lookup tables shouldn't be much larger than 4K entries, unless
performance is absolutely critical. The tables should actually be smaller if at all possible.
A better example would be to consider something
multithreaded, like a web-browser, loading frames.
Any multithreaded program, for that matter, that
might have multiple threads interested in parsing,
needs a multithreaded parser. That is, unless you
enjoy lock contention.
It does not work everywhere. Grow up.
ANSI C has main returning int, so return an int already. I don't see you passing struct timeval as the first argument to printf. Standards exist for a reason.
Actually, I think the way this will end up working
is that everything will be "fogged" by default (mandatory pseudo-white-noise generators placed at regular intervals in public, all content visually and auditorially scrambled, all display devices only supporting scrambled playback), and the helmet would only descramble the things you're licensed for.
You could choose to not wear the helmet, but all you'd get is white noise outside it.
From what I distantly recall of my microelectrons course, your statement is true for BJTs (bipolar junction transistors) but not for FETs. FETs (field effect transistors) are very similar to tubes in their characteristics. Both employ an electric field to control the flow of electrons. In the case of the tube, it's from the cathode to the anode. In the case of the FET, it's from gate to drain.
I'm at least somewhat aware of intermodulation but I decided to not talk about it. Your tech note at the end sums up tube-lover's main argument though: And, some configurations approximately cancel out all odd or even terms. If you cancel out mostly odd terms leaving mostly even terms, at least the result is reasonably melodic, which was my main point.
I personally agree that minimal distortion is best. If you want a "warmer" sound to your music, mix it, equalize it or otherwise process
it that way up front.
Absolutely, the thing is that tubes distort harmonically while solid state amps tend to distort rather dissonantly and horribly.
Huh? They're all harmonics. Tube and certain kinds of FET (field effect transistor) based amps have a "soft limiting", so when they get close to clipping, they tend to generate even harmonics. Three of the first four even harmonics are exactly 1, 2, and 4 octaves away (2nd, 4th, and 8th harmonics), and so this form of distortion tends to be more melodic and pleasant. The 6th, 10th and so on aren't so melodic, but since the amplitude of the harmonics drops as you go to higher harmonics, you're ok.
BJT (bipolar junction transistor) based amps (and other types of solid state amps) tend to clip rather hard. No soft-limiting, they stop right at the rails. This clipping action creates a boatload of odd harmonics. These harmonics are fairly dissonant, giving the harsh sound most people complain about.
I remember trying a version of TweakUI on Win95
way back when (early 96). I seem to recall it had a disable mechanism, but it had the downside that it was permanent. (That is, it noted in the Registry somewhere that TweakUI had been disabled, and there was no option to re-enable anywhere.)
I had thought there was a no-autoraise feature, but my vague recollection isn't very useful, obviously. That *was* 6 years ago.
I think I'm going to have to get TweakUI for my windows machines at work and see how it's improved. If I can do no-autoraise (and turn it off for programs that get confused by it), I'll be a happy camper.
The technology could also be applied to other types of chips, according to the patent. For example, though the patent describes in detail how Transmeta's process would work to create a fast chip that's compatible with Intel silicon, the technique could work for "any family of... computers," even Sun Microsystems' Java technology, the document says.
CISC vs. RISC is a red herring. Today's RISC machines are as complex as today's CISC machines under the hood. The real difference between VLIW machines and current ones is that the VLIWs are statically scheduled whereas other current desktop and workstation CPUs are dynamically scheduled.
Statically scheduled machines rely on compiler software (in the case of Crusoe, the code morphing software) to take a sequence of instructions and determine what order they'll be issued in and what instruction-level parallelism is available.
Dynamically scheduled machines take a serial sequence of instructions, and use large amounts of complex hardware to detect dependences between the instructions. From this, it determines the instruction schedule on the fly.
Statically scheduled processors benefit from greatly simplified instruction decode and dispatch (since no dependence tracking and no real decision making is required aside from conditional branches). Dynamically scheduled processors have some performance benefits insofar as they can make opportunistic scheduling decisions with the additional information that's available at run-time, and not available to the compiler.
On traditional VLIWs, the compiler is usually only able to statically analyse a program and so it may have to schedule conservatively.
A typical example is that the compiler may not be able to tell when two different pointers point to the same thing, so it must serialize accesses via the two separate pointers. Crusoe is able to do a couple things better: First off, the instruction set and hardware provide some mechanisms that allow the machine to speculate sequence of instructions (that is, essentially, make a programmatic guess that a given optimization is OK and check it afterwards, discarding the result on the off-chance it's wrong). Second, it can instrument the code and get on-the-fly branch and function profile data so that it can re-optimize the hot spots more aggressively. Both of these can allow the
statically scheduled Crusoe to approach the performance of dynamically scheduled CPUs in the cases where it would've fallen behind. In a sense, embedding the code-morphing software on an otherwise statically-scheduled device makes it a "blockwise dynamically scheduled" device.
Spelling aside on dependences vs. dependencies. The correct term is dependences when talking about how one instruction depends on another's result. This link gives a primer on the types of dependences that can exist between instructions.
As for energy efficiency: If you're able to get your work done in fewer cycles, you can power the clock off sooner or run it at a much slower rate. Power consumption is linear with respect to clock over lower clock speeds, but as you get to higher speeds, various effects cause non-linear increases in power consumption.
Also, keep in mind that energy efficiency is computational work per Joule. The absolute power consumption may are may not be lower with a more energy efficient part. In this case, they're saying 3x faster and 47% more energy efficient. I read that as meaning approximately, if you compare TM5800 to TM8000 at full-tilt-boogie on a given task, TM8000 will probably dissipate 2x as much power (Watts vs. Watts), but do so for 1/3rd as long.
Another thing to keep in mind is that TM8000 will
probably be on a newer semiconductor process node than TM5800.
I personally use YYYYMMDD for purely numerical dates, say in filenames, for the sorting reasons you mention. For human readable dates, I tend to use
DD-MMM-YYYY, where MMM is a three letter abbrev
for the month (eg. 08-Mar-2002).
FWIW, I'm an American who hates our default "middle-endian" system,
though I'll use it when talking to other Americans.
If you're on a 32-bit word oriented machine,
shouldn't the quote be:
h I" etattiLE elaidn ".n 321032103210321032103210
Ok, maybe that's a little too hard to read, even with the byte-in-word markers.:-)
I've actually gotten used to little endian. I think I like it better than big endian. We do math in little endian, and it makes more sense as long as you write right-to-left (like we do with
numbers).
Microsoft's view seems to be that they pay more taxes than we do so they should have a bigger say in how it's spent.
Hah! Two things: 1. Microsoft has avoided paying millions in taxes by not regularly paying dividends, and instead amassing a $30 billion warchest. 2. You're failing to take into account all the taxes paid by programmers producing GPL code, and all the taxes paid by individuals who use and benefit from that code (and thus have a vested interest in its continued popularity and maintenence). I think they'd like some say in how their tax dollars are allocated.
Huh? I suspect you didn't understand the question.
You're thinking about plugging together a bunch of boards you picked up at Micro Center or George's Local Computer Shop or whatever. That is NOT building from SCRATCH any more than microwaving a TV dinner is cooking food from scratch.
The article is asking about designing a computer from
the component level. That is, getting individual chips, etc. and working from there. For that, I'd recommend taking some digital logic courses, or studying the equivalent material online.
To really know what you're doing, at least well enough to build an early 80s-level computer, you'll need to know the following:
Combinatorial Logic: This will teach you about logic gates, boolean arithmetic, binary numbering systems, and all sorts of digital logic that isn't changing with respect to time.
Sequential Logic: This will teach you how to build state machines and deal with circuits that change state versus time. This builds on the first step.
Microprocessor Interfacing: This teaches about common computer structures, such as data busses, address busses, clocks, and how everything hooks together. A one-semester undergrad course should be sufficient to design something along the lines of an IBM PC XT class machine, if you're good.
That's what I'd recommend. Also, go find schematics for those old machines (Apple ][ computers used to come with schematics, for instance), and study those.
Good luck.
I think you need an auto first to pick up that volatile chick. Although, I think she'll still restrict your actions to the occasional union though. Besides, you have no class.
Slashdot Mirror
C is pass by value for structures also. You get pass-by-reference by passing a pointer to the struct (or whatever you want to pass by reference). The following code example illustrates:
This will print out:
See? Pass by value, not pass by reference.
ObNit #1: Some ABIs actually define the calling convention for structs so that structs are passed by reference. However, if you read closely, those same ABIs also mandate that the callee must copy the argument before writing to it, thereby preserving pass by value semantics. The advantage is that not all calls result in a copy, if the callee treats the struct as read-only.
ObNit #2: C seems like it's pass-by-reference for arrays, but only because it's impossible to have an array argument. You can only pass pointers, structs and scalars to functions. (The subtle irony: Structs can contain arrays.) So, when you want to pass an array to a function, you end up really passing a pointer to the array's first element. (An array reference decays to a pointer to the array's first element.)
--JoeThere is no "proper" way to reduce the precision of a number under all circumstances. Each method of rounding or truncating 0.5 has its own pitfalls:
So, as you can see, there's no right way per se. It just depends on what you're doing.
--JoeYeah, lookup tables are cool. I recently wrote a Life implementation for an old 890kHz CPU. The CPU itself is approximately a 0.1 MIPS device (0.89 MHz, average instruction length around 8 or 9 cycles).
Even on that slow machine, I had Life running at a respectable clip. I used one lookup table to handle packed arithmetic (I did 8 parallel 2-bit adds in a single 16-bit accumulator), and another to handle the life/death state transitions. I used yet another lookup table to map life cells to pixels on the display (since the display has a funky encoding). In the end, I had a 32x24 life field running at about 8 frames per second on that beast. The entire code was about 1K words, and the RAM footprint was tiny too (about 240 bytes for the life state, 32 words for stack, and 240 words of display memory).
You do have to balance lookup tables against raw calculation though. Keep in mind also that lookup tables can lead to local speedups and global slowdowns. On modern machines, for example, lookup tables can thrash out your L1 caches (or in extreme cases, your L2 cache). Remember that optimization is a global problem.
For instance, if you're writing a Variable-Length Code decoder for something like MPEG video decode, you can't just make a lookup table for the maximum code length. Well, technically you could, but since the maximum code length is 26 bits, you'd be in for a 64 mega-entry table. If each table entry is only four bytes, that's 256 megabytes. So obviously, you have to make some engineering tradeoffs.
My personal rule of thumb is that lookup tables shouldn't be much larger than 4K entries, unless performance is absolutely critical. The tables should actually be smaller if at all possible.
--JoeA better example would be to consider something multithreaded, like a web-browser, loading frames. Any multithreaded program, for that matter, that might have multiple threads interested in parsing, needs a multithreaded parser. That is, unless you enjoy lock contention.
--JoeIt does not work everywhere. Grow up. ANSI C has main returning int, so return an int already. I don't see you passing struct timeval as the first argument to printf. Standards exist for a reason.
--JoeNah, with all those strange symbols, it's likely a combination of APL and Befunge.
--JoeActually, I think the way this will end up working is that everything will be "fogged" by default (mandatory pseudo-white-noise generators placed at regular intervals in public, all content visually and auditorially scrambled, all display devices only supporting scrambled playback), and the helmet would only descramble the things you're licensed for.
You could choose to not wear the helmet, but all you'd get is white noise outside it.
--JoeFrom what I distantly recall of my microelectrons course, your statement is true for BJTs (bipolar junction transistors) but not for FETs. FETs (field effect transistors) are very similar to tubes in their characteristics. Both employ an electric field to control the flow of electrons. In the case of the tube, it's from the cathode to the anode. In the case of the FET, it's from gate to drain.
--JoeI'm at least somewhat aware of intermodulation but I decided to not talk about it. Your tech note at the end sums up tube-lover's main argument though: And, some configurations approximately cancel out all odd or even terms. If you cancel out mostly odd terms leaving mostly even terms, at least the result is reasonably melodic, which was my main point.
I personally agree that minimal distortion is best. If you want a "warmer" sound to your music, mix it, equalize it or otherwise process it that way up front.
--JoeHuh? They're all harmonics. Tube and certain kinds of FET (field effect transistor) based amps have a "soft limiting", so when they get close to clipping, they tend to generate even harmonics. Three of the first four even harmonics are exactly 1, 2, and 4 octaves away (2nd, 4th, and 8th harmonics), and so this form of distortion tends to be more melodic and pleasant. The 6th, 10th and so on aren't so melodic, but since the amplitude of the harmonics drops as you go to higher harmonics, you're ok.
BJT (bipolar junction transistor) based amps (and other types of solid state amps) tend to clip rather hard. No soft-limiting, they stop right at the rails. This clipping action creates a boatload of odd harmonics. These harmonics are fairly dissonant, giving the harsh sound most people complain about.
But they're all harmonics.
--JoeI remember trying a version of TweakUI on Win95 way back when (early 96). I seem to recall it had a disable mechanism, but it had the downside that it was permanent. (That is, it noted in the Registry somewhere that TweakUI had been disabled, and there was no option to re-enable anywhere.) I had thought there was a no-autoraise feature, but my vague recollection isn't very useful, obviously. That *was* 6 years ago.
I think I'm going to have to get TweakUI for my windows machines at work and see how it's improved. If I can do no-autoraise (and turn it off for programs that get confused by it), I'll be a happy camper.
--JoeOr, to read mail from relatives and friends you met on Slashdot:
Works best if you're root.
--JoeIncidentally, if you like strace on Linux, the truss command under Solaris is very similar.
For really complex problems, be sure to look into the -o and -f flags.
--JoeCan you also turn off autoraise? Move-to-focus is worthless for me if autoraise is on.
--JoeActually, I believe this article says as much:
--JoeCISC vs. RISC is a red herring. Today's RISC machines are as complex as today's CISC machines under the hood. The real difference between VLIW machines and current ones is that the VLIWs are statically scheduled whereas other current desktop and workstation CPUs are dynamically scheduled.
Statically scheduled machines rely on compiler software (in the case of Crusoe, the code morphing software) to take a sequence of instructions and determine what order they'll be issued in and what instruction-level parallelism is available.
Dynamically scheduled machines take a serial sequence of instructions, and use large amounts of complex hardware to detect dependences between the instructions. From this, it determines the instruction schedule on the fly.
Statically scheduled processors benefit from greatly simplified instruction decode and dispatch (since no dependence tracking and no real decision making is required aside from conditional branches). Dynamically scheduled processors have some performance benefits insofar as they can make opportunistic scheduling decisions with the additional information that's available at run-time, and not available to the compiler.
On traditional VLIWs, the compiler is usually only able to statically analyse a program and so it may have to schedule conservatively. A typical example is that the compiler may not be able to tell when two different pointers point to the same thing, so it must serialize accesses via the two separate pointers. Crusoe is able to do a couple things better: First off, the instruction set and hardware provide some mechanisms that allow the machine to speculate sequence of instructions (that is, essentially, make a programmatic guess that a given optimization is OK and check it afterwards, discarding the result on the off-chance it's wrong). Second, it can instrument the code and get on-the-fly branch and function profile data so that it can re-optimize the hot spots more aggressively. Both of these can allow the statically scheduled Crusoe to approach the performance of dynamically scheduled CPUs in the cases where it would've fallen behind. In a sense, embedding the code-morphing software on an otherwise statically-scheduled device makes it a "blockwise dynamically scheduled" device.
Spelling aside on dependences vs. dependencies . The correct term is dependences when talking about how one instruction depends on another's result. This link gives a primer on the types of dependences that can exist between instructions.
As for energy efficiency: If you're able to get your work done in fewer cycles, you can power the clock off sooner or run it at a much slower rate. Power consumption is linear with respect to clock over lower clock speeds, but as you get to higher speeds, various effects cause non-linear increases in power consumption.
Also, keep in mind that energy efficiency is computational work per Joule. The absolute power consumption may are may not be lower with a more energy efficient part. In this case, they're saying 3x faster and 47% more energy efficient. I read that as meaning approximately, if you compare TM5800 to TM8000 at full-tilt-boogie on a given task, TM8000 will probably dissipate 2x as much power (Watts vs. Watts), but do so for 1/3rd as long.
Another thing to keep in mind is that TM8000 will probably be on a newer semiconductor process node than TM5800.
--JoeI personally use YYYYMMDD for purely numerical dates, say in filenames, for the sorting reasons you mention. For human readable dates, I tend to use DD-MMM-YYYY, where MMM is a three letter abbrev for the month (eg. 08-Mar-2002).
FWIW, I'm an American who hates our default "middle-endian" system, though I'll use it when talking to other Americans.
--JoeIf you're on a 32-bit word oriented machine, shouldn't the quote be:
Ok, maybe that's a little too hard to read, even with the byte-in-word markers. :-)
I've actually gotten used to little endian. I think I like it better than big endian. We do math in little endian, and it makes more sense as long as you write right-to-left (like we do with numbers).
--JoeHah! Two things: 1. Microsoft has avoided paying millions in taxes by not regularly paying dividends, and instead amassing a $30 billion warchest. 2. You're failing to take into account all the taxes paid by programmers producing GPL code, and all the taxes paid by individuals who use and benefit from that code (and thus have a vested interest in its continued popularity and maintenence). I think they'd like some say in how their tax dollars are allocated.
--JoeYou mean, like this?
--Joe
Huh? I suspect you didn't understand the question. You're thinking about plugging together a bunch of boards you picked up at Micro Center or George's Local Computer Shop or whatever. That is NOT building from SCRATCH any more than microwaving a TV dinner is cooking food from scratch.
The article is asking about designing a computer from the component level. That is, getting individual chips, etc. and working from there. For that, I'd recommend taking some digital logic courses, or studying the equivalent material online.
To really know what you're doing, at least well enough to build an early 80s-level computer, you'll need to know the following:
That's what I'd recommend. Also, go find schematics for those old machines (Apple ][ computers used to come with schematics, for instance), and study those. Good luck.
--JoeI think you need an auto first to pick up that volatile chick. Although, I think she'll still restrict your actions to the occasional union though. Besides, you have no class.
--JoeCool. Thanks!
--JoeHey, can you send me a copy of that sound? Pretty please? Or at least point me somewhere where I can find it other than KaZaa, such as a webpage?
--JoeNot to mention that there are probably still microbes living on the stuff we left on the moon in the 60s...
--Joe