 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jan Walzer <jan### [at] lzer net> wrote:
> I'm wondering, what kind of instruction word this ASM-interpreter uses ...
> are they more CISC- or more RISC- like ? ...
That depends on how you define CISC and RISC.
I don't think there are really many instructions, so one could say that
it's a "reduced instruction set". However, one typical feature of CISC is
that each instruction takes the same amount of memory and 1 clock cycle to
execute, which I don't think is the case.
> BTW: What 'bout self-modifying code ? ... that would be nice ... back to oldschool
I doubt that you have any possibility of writing to memory.
--
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3ca5bf52@news.povray.org>, Warp <war### [at] tagpovrayorg>
wrote:
> > BTW: What 'bout self-modifying code ? ... that would be nice ... back to
> > oldschool
>
> I doubt that you have any possibility of writing to memory.
Depends on what you mean by self modifying...POV-Script could probably
output a function ASM file and then load it as a function.
--
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" <war### [at] tagpovrayorg> schrieb im Newsbeitrag news:3ca5bf52@news.povray.org...
> Jan Walzer <jan### [at] lzernet> wrote:
> > I'm wondering, what kind of instruction word this ASM-interpreter uses ...
>
> > are they more CISC- or more RISC- like ? ...
>
> That depends on how you define CISC and RISC.
> I don't think there are really many instructions, so one could say that
> it's a "reduced instruction set". However, one typical feature of CISC is
> that each instruction takes the same amount of memory and 1 clock cycle to
> execute, which I don't think is the case.
That is RISC ... the reduced instructionset normally has every opcode same
length (4Bytes on a 32Bit-architecture (look_at MIPS))... This is the criteria
I wanted to ask. OTOH CISC has different length opcodes, that are interpreted by
an microcode, where normally different runtimes for different ops can be seen ...
... of course, the time, needed for execution of an operation is not necessary the
same for all instructions of a RISC machine, too ...
I see now, that my question was not exactly formulated ...
I better should have asked: will the ASM-code more base on Load-Store-arch (which
is "quite" common for RISC) or will it be more like Work-Direct-In-Mem-arch (which
is more common for CISC) ...
> > > BTW: What 'bout self-modifying code ? ... that would be nice ... back to
> > > oldschool
> > I doubt that you have any possibility of writing to memory.
[CJH]> Depends on what you mean by self modifying...POV-Script could probably
[CJH]> output a function ASM file and then load it as a function.
No ... this is not what I meant ... I mean, that the prog, can modify itself
in memory, to speedup execution ...
... or to make unreadable code ...
Post a reply to this message
|
|
| |
| |
|
|
From: Thorsten Froehlich
Subject: Re: function optimization question
Date: 31 Mar 2002 10:24:09
Message: <3ca72a19@news.povray.org>
|
|
|
| |
| |
|
|
In article <3ca5bf52@news.povray.org> , Warp <war### [at] tagpovrayorg> wrote:
> That depends on how you define CISC and RISC.
> I don't think there are really many instructions, so one could say that
> it's a "reduced instruction set". However, one typical feature of CISC is
> that each instruction takes the same amount of memory and 1 clock cycle to
> execute, which I don't think is the case.
It shows some typical RISC characteristics: Each instruction takes the same
amount of memory (usually 4 bytes or whatever two shorts in a struct will need
depending on the compiler/platform used) and it is designed as load/store
architecture. As for execution time, basic instructions offer somewhere
around 1/10 to 1/20 of the target architecture speed.
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
ahh ... thx Thorsten ... that's what I wanted to know ...
... YES! ... /me want's this feature, accessible from Userspace (ie. not by patches)
and with _FULL DOCUMENTATION_ ... *g*
Post a reply to this message
|
|
| |
| |
|
|
From: Thorsten Froehlich
Subject: Re: function optimization question
Date: 31 Mar 2002 10:45:45
Message: <3ca72f29@news.povray.org>
|
|
|
| |
| |
|
|
In article <3ca6f75f$1@news.povray.org> , "Jan Walzer" <jan### [at] lzernet> wrote:
> No ... this is not what I meant ... I mean, that the prog, can modify itself
> in memory, to speedup execution ...
> ... or to make unreadable code ...
Which would make it close to impossible to just-in-time compile anything.
Anyway, here is a list from the source code. It may not be fully up-to-date
and probably won't we very readable in a newsreader, but that is what text
editiors and printers are for :-)
Thorsten
- - - - - - - - -
# Rs = R0 - R7, one of eight floating-point registers
# Rd = R0 - R7, one of eight floating-point registers
# k = constant, can be DBL or int depending on function
# SP = data stack point
# PSP = program stack pointer
# CC = condition code register
# PC = program counter
# global = global variable data space
# local = local variable data space
# const = const floating-point value data space
# eq = equal
# ne = not equal
# lt = lower
# le = lower or equal
# gt = greater
# ge = greater or equal
R-Type Instructions (9 * 64 = 576)
Opcode|Source| Dest | k-data |Instruction | Operation
4 bits|3 bits|3 bits|16 bits | |
------+------+------+--------+--------------+-----------------------------
00 | Rs | Rd | 0000 | add Rs, Rd | Rd + Rs -> Rd
01 | Rs | Rd | 0000 | sub Rs, Rd | Rd - Rs -> Rd
02 | Rs | Rd | 0000 | mul Rs, Rd | Rd * Rs -> Rd
03 | Rs | Rd | 0000 | div Rs, Rd | Rd / Rs -> Rd
04 | Rs | Rd | 0000 | mod Rs, Rd | Rd % Rs -> Rd
05 | Rs | Rd | 0000 | move Rs, Rd | Rs -> Rd
06 | Rs | Rd | 0000 | cmp Rs, Rd | Rd - Rs -> CC
07 | Rs | Rd | 0000 | neg Rs, Rd | -Rs -> Rd
08 | Rs | Rd | 0000 | abs Rs, Rd | |Rs| -> Rd
I-Type Instructions (7 * 8 = 56)
Opcode|Ext.Op| Dest | k-data |Instruction | Operation
4 bits|3 bits|3 bits|16 bits | |
------+------+------+--------+--------------+-----------------------------
09 | 00 | Rd |const(k)|addi c, Rd | Rd + const(k) -> Rd
09 | 01 | Rd |const(k)|subi c, Rd | Rd - const(k) -> Rd
09 | 02 | Rd |const(k)|muli c, Rd | Rd * const(k) -> Rd
09 | 03 | Rd |const(k)|divi c, Rd | Rd / const(k) -> Rd
09 | 04 | Rd |const(k)|modi c, Rd | Rd % const(k) -> Rd
09 | 05 | Rd |const(k)|loadi c, Rd | const(k) -> Rd
09 | 06 | Rd |const(k)|cmpi c, Rd | Rd - const(k) -> CC
JS-Type Instructions (6 * 8 = 48)
Opcode|Ext.Op| Dest | k-data |Instruction | Operation
4 bits|3 bits|3 bits|16 bits | |
------+------+------+--------+--------------+-----------------------------
10 | 00 | Rd | 0000 |seq Rd | (CC = eq) -> Rd
10 | 01 | Rd | 0000 |sne Rd | (CC = ne) -> Rd
10 | 02 | Rd | 0000 |slt Rd | (CC = lt) -> Rd
10 | 03 | Rd | 0000 |sle Rd | (CC = le) -> Rd
10 | 04 | Rd | 0000 |sgt Rd | (CC = gt) -> Rd
10 | 05 | Rd | 0000 |sge Rd | (CC = ge) -> Rd
10 | 06 | Rd | 0000 |teq Rd | (Rd == 0) -> Rd
10 | 07 | Rd | 0000 |tne Rd | (Rd != 0) -> Rd
ML-Type Instructions (2 * 8 = 16)
Opcode|Ext.Op| Dest | k-data |Instruction | Operation
4 bits|3 bits|3 bits|16 bits | |
------+------+------+--------+--------------+-----------------------------
11 | 00 | Rd | 0000 |load 0(k), Rd | global(k) -> Rd
11 | 01 | Rd | 0000 |load SP(k), Rd| local(k) -> Rd
MS-Type Instructions (2 * 8 = 16)
Opcode|Ext.Op|Source| k-data |Instruction | Operation
4 bits|3 bits|3 bits|16 bits | |
------+------+------+--------+--------------+-----------------------------
12 | 00 | Rs | 0000 |store Rs, 0(k)| Rs -> global(k)
12 | 01 | Rs | 0000 |store Rs, SP(k)| Rs -> local(k)
JB-Type Instructions (6)
Opcode|Ext.Op|Unused| k-data |Instruction | Operation
4 bits|3 bits|3 bits|16 bits | |
------+------+------+--------+--------------+-----------------------------
13 | 00 | 00 | offset |beq k | if (CC = eq) then k -> PC
13 | 01 | 00 | offset |bne k | if (CC = ne) then k -> PC
13 | 02 | 00 | offset |blt k | if (CC = lt) then k -> PC
13 | 03 | 00 | offset |ble k | if (CC = le) then k -> PC
13 | 04 | 00 | offset |bgt k | if (CC = gt) then k -> PC
13 | 05 | 00 | offset |bge k | if (CC = ge) then k -> PC
XS-Type Instructions (6 * 8 = 48)
Opcode|Ext.Op|Source| k-data |Instruction | Operation
4 bits|3 bits|3 bits|16 bits | |
------+------+------+--------+--------------+-----------------------------
14 | 00 | Rs | 0000 |xeq Rs | if (Rs == 0) then exception
14 | 01 | Rs | 0000 |xne Rs | if (Rs != 0) then exception
14 | 02 | Rs | 0000 |xlt Rs | if (Rs < 0) then exception
14 | 03 | Rs | 0000 |xle Rs | if (Rs <= 0) then exception
14 | 04 | Rs | 0000 |xgt Rs | if (Rs > 0) then exception
14 | 05 | Rs | 0000 |xge Rs | if (Rs >= 0) then exception
14 | 06 | Rs | 0000 |xdz R0, Rs | if (R0 == 0) && (Rs == 0) then
exception
X-Type Instructions (11)
Opcode|Ext.Op| k-data |Instruction | Operation
4 bits|6 bits|16 bits | |
------+------+--------+--------------+--------------------------------
15 | 00 | 0000 |jsr k | PSP + 1 -> PSP, PC -> (PSP), k -> PC
15 | 01 | 0000 |jmp k | k -> PC
15 | 02 | 0000 |rts | (PSP) -> PC, PSP - 1 -> PSP
15 | 03 | 0000 |call k | calls user-defined function k, result
will be in R0
15 | 04 | 0000 |sys1 k | calls internal function k with one
argument, result will be in R0
15 | 05 | 0000 |sys2 k | calls internal function k with two
arguments, result will be in R0
15 | 06 | 0000 |trap k | calls internal function k with
arguments on stack, result will be in R0
15 | 07 | 0000 |traps k | calls internal function k with
arguments on stack, result will be on the stack
15 | 08 | 0000 |grow k | grow the stack to hold k elements
(floating-point numbers)
15 | 09 | 0000 |push k | move the stack pointer k elements
forward
15 | 10 | 0000 |pop k | move the stack pointer k elements
backward
15 | 63 | 0000 |nop | no operation
Total number of defined instructions: 780
Density of instruction set: 780 / 1024 = 0.7617
OF COURSE THIS IS ALL SUBJECT TO COMPLETE CHANGE AND REDESIGN IN CURRENT AND
FUTURE VERSIONS OF POV-RAY!
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ahh... This list awakens warm memories from the time I coded in asm for
Spectrum and later for DOS.
It really is starting to look like something I would like to code in
the future.
Making a pattern with asm-code. Cool.
--
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3ca6f75f$1@news.povray.org>, "Jan Walzer" <jan### [at] lzernet>
wrote:
> No ... this is not what I meant ... I mean, that the prog, can modify itself
> in memory, to speedup execution ...
Well, what's stopping you? You would have to interface through the
ordinary POV-Script and write it to the disk in order to load it again,
but the result would be the same: dynamically generated code being
loaded into memory and executed. Just a bit roundabout, and a large
chunk of the required code would have to be written in POV-Script
instead of being done by the function engine. It would also be very
slow...
Hmm, maybe write a VM in POV-Script. ;-)
> ... or to make unreadable code ...
It would certainly do this well.
--
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Christopher James Huff" <chr### [at] maccom> wrote:
> > No ... this is not what I meant ... I mean, that the prog, can modify itself
> > in memory, to speedup execution ...
>
> Well, what's stopping you? You would have to interface through the
> ordinary POV-Script and write it to the disk in order to load it again,
> but the result would be the same: dynamically generated code being
> loaded into memory and executed. Just a bit roundabout, and a large
> chunk of the required code would have to be written in POV-Script
> instead of being done by the function engine. It would also be very
> slow...
nope... that's not what I meant...
Consider this pseudo-code
-----------------------------------
A=SomeExpression(Input)
repeat
DoSomething()
if (A=SomeValue)
FarCall SubRoutine1
else
NearCall SubRoutine2
endif
DoSomethingElse()
until (End)
------------------------------------
as you can see: the if-instruction is executed very often...
In Self-modifying-ASM-code one could write:
------------------------------------
A=SomeExpression(Input)
if (A=SomeValue)
[ChangeHere]=OpCodeOf(FarCall SubRoutine1)
else
[ChangeHere]=OpCodeOf(NearCall SubRoutine2)
endif
repeat
DoSomething()
:ChangeHere
noop
noop
noop
noop
DoSomethingElse()
until (End)
------------------------------------
I once had a chance, to speed up the Bresenham by a factor of 3 by a similar method.
The thing is that you can decide at runtime, which opcodes get executed, depending
on some runtime values
As there are(were) different opcodes used for a near-jump (target-address, beein in
the same codesegment) and a far-jump (jump to anywhere in memory) there was no easy
chance, to work only with pointers, and only change these...
Of course, my last lines applied to my active assembler time, when I did some
x86-Realmode ASM ....
I hope you got the idea ...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ahhh ... nice ...
Thats what I wanted to read ...
Seems very complete and useful ...
Will this get included into the official doc ? ...
I would much apreciate this ...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
