Craigix, Free Units To Devs?

[skeezix]

Heres an _anecdone_ (by no means an example of a trend, just an isolated case). Aside from being good-usage or bad-usage, sometimes its just great for pure optimization; sometimes when you do edge case optimization, you break the rules of good taste. (Often

ie: I was working on a CPU emu core (for cinematronics in fact), based on reference assembly from the amazing Zonn. (My core eventually got donated to MAME, and then I think Aaron came along and rewrote it to be more clear and less evil Anyway --

This was back at the time when machines were very slow (none of this Ghz business) so it needed to perform very fast; I think this was Pentium1 days so 60Mhz was not uncommon. Writing it in a sane fashion made it useless, but I chose to write it as a pure dstate machine in one function, with gotos. There was no function calls or looping or the like .. it was all switch/goto (if was too slow).

I made it not too ugly through use of lots of #define macros (and at one point a preprocessor to emit the code from a set of config files), but even then.. the resulting code was not _that_ ugly, and it was _extremely fast_. Function call overhead was too much, if-state,ment overhead was too much

So I'm a fan of good-usage, but sometimes you need to go low level .. without resorting to pure-ASM since I wanted to support multiple chips, etc.

Try explaining this to someone using a rich interpreted or VM'd language 5 layers removed, running on a multi-ghz multi-core machine

jeff

 

[Dead1nside]

If this thread is still about getting units into devs hands either at OpenPandora's cost or some other way, I'd be in support of a separate dev fund (which seems to be geared towards software contributions) I'd happily put £10 into some sort of fund to buy devs units or subsidise them. Probably come up before.

 

[Exophase]

Heres an _anecdone_ (by no means an example of a trend, just an isolated case). Aside from being good-usage or bad-usage, sometimes its just great for pure optimization; sometimes when you do edge case optimization, you break the rules of good taste. (Often

ie: I was working on a CPU emu core (for cinematronics in fact), based on reference assembly from the amazing Zonn. (My core eventually got donated to MAME, and then I think Aaron came along and rewrote it to be more clear and less evil Anyway --

This was back at the time when machines were very slow (none of this Ghz business) so it needed to perform very fast; I think this was Pentium1 days so 60Mhz was not uncommon. Writing it in a sane fashion made it useless, but I chose to write it as a pure dstate machine in one function, with gotos. There was no function calls or looping or the like .. it was all switch/goto (if was too slow).

I made it not too ugly through use of lots of #define macros (and at one point a preprocessor to emit the code from a set of config files), but even then.. the resulting code was not _that_ ugly, and it was _extremely fast_. Function call overhead was too much, if-state,ment overhead was too much

So I'm a fan of good-usage, but sometimes you need to go low level .. without resorting to pure-ASM since I wanted to support multiple chips, etc.

Try explaining this to someone using a rich interpreted or VM'd language 5 layers removed, running on a multi-ghz multi-core machine

jeff

Do you still have this code? I'd be interested in seeing it.

When you say switches instead of ifs, do you mean instead of if-chains for lots of cases? Because a switch with one case and a default will get turned into the same thing as an if in any compiler that isn't really silly.

I had a programming languages class in grad school, which I actually had to TA the next year, that had a section on turning Scheme programs into C ones. The end result was largely a mess of switches and gotos, since C's functions don't fit well with Scheme ones (have to guarantee tail recursion). The professor told a story of how someone used this approach to get the best performance in the class in an algorithms course.

 

[skeezix]

I probably do have it around, but you can imagine most of it already.

In essence, the cinematronics 'cpu' (really just amess of wires that pretends to act like a lossy CPU. Yes, it can loose bits during arithmetic shifts, if I recall right. 20 bit words with a lossy bitin the mddle or somerhing.. been a long time anyway

The thing could really operate in a few states, and in each state the opcodes would work a little differently; theres many ways of approaching it, but the way Zonn did it and the way I ended up modelling the code, was in essence..

top:

switch ( state )

switch ( opcode)
switch ( something else)

switch (another opcode )
..

various cases would goto-top

if I recall right; anyway, i twas to avoid tables of func-call-ptrs, avoid chained-if's, avoid other methods of decoding the opcode and params. I don't recall particulars, but the goal was one function that did heavy lifitng; no if-statements, no returning, no loops, etc.

The 'at the time' prevalent method of coding CPU cores (think Marat Z80 etc) was very function heavy and you could see the impact of the function call overheads and redundant loops; the above approach was rather a crude unroll of sorts, but worked brillianly. Combine with the levle of optims that gcc could do at the time, the slow CPUs etc, and it was just enough.

In the end, could run a Cinematronics emulation on old Palm OS devices and have a half-chance of performing 'ok', which was something (those came much later, but I revived the code for Palm OS for fun. Of course, a few people (even a GP32 guy) wrote a static recompiler which ruled the day, but I liked my attempt all the same.)

jeff

 

[Pleng]

<snip>
And I'll optimise that for you:

10 goto 10

<snip>

:lol: Probably the best goto comment so far.

Should probably factor in some basic error checking:

10 if 1 > 0 then goto 10

There