Hi All, I wonder if anyone has any 32-bit processor implementations, either in Smalltalk or in some other, preferrably easy-to-parse, formal semantics. In implementing the new JIT VM I would like to continue developing in Smalltalk using VMMaker/Slang, but this implies having a processor simulation in Smalltalk to produce actual machine code for. Ideally this would be an x86 of some description (doesn't need to be bang up to date, 386 would be fine). I'd also welcome an ARM.
TIA
2008/10/31 Eliot Miranda eliot.miranda@gmail.com:
Hi All, I wonder if anyone has any 32-bit processor implementations, either in Smalltalk or in some other, preferrably easy-to-parse, formal semantics. In implementing the new JIT VM I would like to continue developing in Smalltalk using VMMaker/Slang, but this implies having a processor simulation in Smalltalk to produce actual machine code for. Ideally this would be an x86 of some description (doesn't need to be bang up to date, 386 would be fine). I'd also welcome an ARM. TIA
Hi Eliot. To my knowledge, Exupery is the only project which dealing with assembly code. There are some mechanisms to define instructions.
On Thu, Oct 30, 2008 at 6:21 PM, Igor Stasenko siguctua@gmail.com wrote:
2008/10/31 Eliot Miranda eliot.miranda@gmail.com:
Hi All, I wonder if anyone has any 32-bit processor implementations, either
in
Smalltalk or in some other, preferrably easy-to-parse, formal semantics.
In
implementing the new JIT VM I would like to continue developing in
Smalltalk
using VMMaker/Slang, but this implies having a processor simulation in Smalltalk to produce actual machine code for. Ideally this would be an
x86
of some description (doesn't need to be bang up to date, 386 would be
fine).
I'd also welcome an ARM. TIA
Hi Eliot. To my knowledge, Exupery is the only project which dealing with assembly code. There are some mechanisms to define instructions.
I understand that. But I'm not too interested in code generation (I can write this myself or adapt other code). What I need is a processor simulation to generate code for, preferrably a clone of an x86, one that executes its own instruction set. Then I can test the JIT in Smalltalk.
I believe Peter Deutsch write a 68000 simulator when he implemented PS, the first Smalltalk-80 JIT, but I could be wrong and perhaps he only implemented an assembler for the 68000.
-- Best regards, Igor Stasenko AKA sig.
Why don't you use Valgrind with Callgrind or Cachegrind :
Cachegrind
Cachegrind is a cache profiler. It performs detailed simulation of the I1, D1 and L2 caches in your CPU and so can accurately pinpoint the sources of cache misses in your code. It identifies the number of cache misses, memory references and instructions executed for each line of source code, with per-function, per-module and whole-program summaries. It is useful with programs written in any language. Cachegrind runs programs about 20--100x slower than normal. Callgrind Callgrind, by Josef Weidendorfer, is an extension to Cachegrind. It provides all the information that Cachegrind does, plus extra information about callgraphs. It was folded into the main Valgrind distribution in version 3.2.0. Available separately is an amazing visualisation tool, KCachegrind, which gives a much better overview of the data that Callgrind collects; it can also be used to visualise Cachegrind's output.
On 10/31/08 2:36 AM, Eliot Miranda wrote:
On Thu, Oct 30, 2008 at 6:21 PM, Igor Stasenko <siguctua@gmail.com mailto:siguctua@gmail.com> wrote:
2008/10/31 Eliot Miranda <eliot.miranda@gmail.com <mailto:eliot.miranda@gmail.com>>: > Hi All, > I wonder if anyone has any 32-bit processor implementations, either in > Smalltalk or in some other, preferrably easy-to-parse, formal semantics. In > implementing the new JIT VM I would like to continue developing in Smalltalk > using VMMaker/Slang, but this implies having a processor simulation in > Smalltalk to produce actual machine code for. Ideally this would be an x86 > of some description (doesn't need to be bang up to date, 386 would be fine). > I'd also welcome an ARM. > TIA > Hi Eliot. To my knowledge, Exupery is the only project which dealing with assembly code. There are some mechanisms to define instructions.I understand that. But I'm not too interested in code generation (I can write this myself or adapt other code). What I need is a processor simulation to generate code for, preferrably a clone of an x86, one that executes its own instruction set. Then I can test the JIT in Smalltalk.
I believe Peter Deutsch write a 68000 simulator when he implemented PS, the first Smalltalk-80 JIT, but I could be wrong and perhaps he only implemented an assembler for the 68000.
> > -- Best regards, Igor Stasenko AKA sig.
On Fri, Oct 31, 2008 at 4:08 AM, Gwenael Casaccio mrgwen@gmail.com wrote:
Why don't you use Valgrind with Callgrind or Cachegrind :
It's an idea. I guess because my need is for an efficient simulation of the ISA, not a detailed performance analysis of the CPU, this doesn't seem compelling. But it might be a way to optimize the JIT's code generator.
Thanks.
Cachegrind
Cachegrind is a cache profiler. It performs detailed simulation of the I1, D1 and L2 caches in your CPU and so can accurately pinpoint the sources of cache misses in your code. It identifies the number of cache misses, memory references and instructions executed for each line of source code, with per-function, per-module and whole-program summaries. It is useful with programs written in any language. Cachegrind runs programs about 20--100x slower than normal. Callgrind Callgrind, by Josef Weidendorfer, is an extension to Cachegrind. It provides all the information that Cachegrind does, plus extra information about callgraphs. It was folded into the main Valgrind distribution in version 3.2.0. Available separately is an amazing visualisation tool, KCachegrind, which gives a much better overview of the data that Callgrind collects; it can also be used to visualise Cachegrind's output.
On 10/31/08 2:36 AM, Eliot Miranda wrote:
On Thu, Oct 30, 2008 at 6:21 PM, Igor Stasenko <siguctua@gmail.com mailto:siguctua@gmail.com> wrote:
2008/10/31 Eliot Miranda <eliot.miranda@gmail.com mailto:eliot.miranda@gmail.com>:
> Hi All, > I wonder if anyone has any 32-bit processor implementations,either in > Smalltalk or in some other, preferrably easy-to-parse, formal semantics. In > implementing the new JIT VM I would like to continue developing in Smalltalk > using VMMaker/Slang, but this implies having a processor simulation in > Smalltalk to produce actual machine code for. Ideally this would be an x86 > of some description (doesn't need to be bang up to date, 386 would be fine). > I'd also welcome an ARM. > TIA >
Hi Eliot. To my knowledge, Exupery is the only project which dealing with assembly code. There are some mechanisms to define instructions.
I understand that. But I'm not too interested in code generation (I can write this myself or adapt other code). What I need is a processor simulation to generate code for, preferrably a clone of an x86, one that executes its own instruction set. Then I can test the JIT in Smalltalk.
I believe Peter Deutsch write a 68000 simulator when he implemented PS, the first Smalltalk-80 JIT, but I could be wrong and perhaps he only implemented an assembler for the 68000.
> >-- Best regards, Igor Stasenko AKA sig.
Eliot Miranda wrote:
I wonder if anyone has any 32-bit processor implementations,either in Smalltalk or in some other, preferrably easy-to-parse, formal semantics.
I thought about this several times, but never came down to implement it: The Intel manuals do have a very concrete pseudocode for every instruction, and it does look quite parsable. I did start once, but the need for it disappeared, and I never finished...
the description for ADD is:
DEST ← DEST + SRC + CF;
and for AAA (Ascii adjust after addition) is more complex: IF 64-Bit Mode THEN #UD; ELSE IF ((AL AND 0FH) > 9) or (AF = 1) THEN AL ← AL + 6; AH ← AH + 1; AF ← 1; CF ← 1; AL ← AL AND 0FH; ELSE AF ← 0; CF ← 0; AL ← AL AND 0FH; FI; FI;
I think it really is an option to write a compiler from PDF to Smalltalk :)
richie
On Fri, Oct 31, 2008 at 12:21 PM, Gerardo Richarte gera@corest.com wrote:
I think it really is an option to write a compiler from PDF to Smalltalk :)
Yup, after the RFC table parser, that would be another nice use-case of OMeta :)
On Fri, Oct 31, 2008 at 4:21 AM, Gerardo Richarte gera@corest.com wrote:
Eliot Miranda wrote:
I wonder if anyone has any 32-bit processor implementations,either in Smalltalk or in some other, preferrably easy-to-parse, formal semantics.
I thought about this several times, but never came down to implementit: The Intel manuals do have a very concrete pseudocode for every instruction, and it does look quite parsable. I did start once, but the need for it disappeared, and I never finished...
the description for ADD is:
DEST ← DEST + SRC + CF;
and for AAA (Ascii adjust after addition) is more complex: IF 64-Bit Mode THEN #UD; ELSE IF ((AL AND 0FH) > 9) or (AF = 1) THEN AL ← AL + 6; AH ← AH + 1; AF ← 1; CF ← 1; AL ← AL AND 0FH; ELSE AF ← 0; CF ← 0; AL ← AL AND 0FH; FI; FI;
I think it really is an option to write a compiler from PDF to Smalltalk :)
richie
Superficially this looks good. But it is only a part of the semantics. This is a fairly abstract semantics. It leaves out definitions of registers (e.g. DEST ← DEST + SRC + CF;) and all the instruction decode, which on x86 is complex and easy to screw up.
Eliot Miranda wrote:
Superficially this looks good. But it is only a part of the semantics. This is a fairly abstract semantics. It leaves out definitions of registers (e.g. DEST ← DEST + SRC + CF;) and all the instruction decode, which on x86 is complex and easy to screw up.
if you find anything better, please let me know. I'm still interested in this.
Appendix B, on the second part of the Instrution Set Reference manual (http://www.intel.com/products/processor/manuals/). I couldn't find it now, I'll see if I can find it home, but somewhere I have a Squeak implementation of a IA-32 decompiler. At that time I based on an old text version of the table "General Purpose Instruction Formats and Encodings for Non-64-Bit Modes" in that document. I remember that after some tweaking I could "compile" the table. This is when I started trying to compile the pseudocode for instruction, but I never got too far with it.
Another place where to find "compilable" information of how to decode the instructions is in the header of each instruction on the same manual. It is a very precise specification, for example:
64-Bit Compat/ Opcode Instruction Mode Leg Mode Description 04 ib ADD AL, imm8 Valid Valid Add imm8 to AL. 05 iw ADD AX, imm16 Valid Valid Add imm16 to AX. 05 id ADD EAX, imm32 Valid Valid Add imm32 to EAX.
01 /r ADD r/m16, r16 Valid Valid Add r16 to r/m16. 01 /r ADD r/m32, r32 Valid Valid Add r32 to r/m32. 02 /r ADD r8, r/m8 Valid Valid Add r/m8 to r8. ADD r8*, r/m8* Valid N.E. Add r/m8 to r8.
the r/m notation has a very precise meaning and encoding, so does the /r and r32. Yes, there are some asterisks, but they are clearly marked. Again, I'm interested in any options you find!
richie
Eliot Miranda wrote on Thu, 30 Oct 2008 18:15:24 -0700
I wonder if anyone has any 32-bit processor implementations, either in Smalltalk or in some other, preferrably easy-to-parse, formal semantics.
I have a simulator for the 16 bit stack processor in Squeak, but I don't think it would be very interesting for you. For Smalltalk compatible formal semantics there is IDaSS (http://www.xs4all.nl/~averschu/idass/) on VisualWorks but all their examples are 8 bit.
You can find many processor implementations in VHDL, Verilog and other hardware design languages but the effort of dealing with any of these languages would far outweigh just writting a new simulator in Smalltalk. And they would probably be too low level for your needs in any case. You can find more suitable simulators in C, Java and similar languages.
In implementing the new JIT VM I would like to continue developing in Smalltalk using VMMaker/Slang,
Good plan!
but this implies having a processor simulation in Smalltalk to produce actual machine code for. Ideally this would be an x86 of some description (doesn't need to be bang up to date, 386 would be fine). I'd also welcome an ARM.
I wrote simulators for the 8086 and ARM2 back in 1988 and can tell you that the first is much more troublesome. Both architectures have grown more complicated since then but the x86 has done so exponentially. Just to give you an idea of how bad things are now, the RAMP people (http://ramp.eecs.berkeley.edu/) had initially planned to have a x86 implementation as one of their core options but even with all their resources they eventually had to give up and now run QEMU on Sparc cores instead!
One processor that has been implemented many times and has many formal descriptions floating around on the web is the MIPS-like academic DLX design presented in the Hennessy & Patterson textbook.
-- Jecel
Hi Jecel
On Nov 5, 2008, at 11:43 PM, Jecel Assumpcao Jr wrote:
Eliot Miranda wrote on Thu, 30 Oct 2008 18:15:24 -0700
I wonder if anyone has any 32-bit processor implementations,either in Smalltalk or in some other, preferrably easy-to-parse, formal semantics.
I have a simulator for the 16 bit stack processor in Squeak, but I don't think it would be very interesting for you.
Where did you publish it?
For Smalltalk compatible formal semantics there is IDaSS (http://www.xs4all.nl/~averschu/ idass/) on VisualWorks but all their examples are 8 bit.
You can find many processor implementations in VHDL, Verilog and other hardware design languages but the effort of dealing with any of these languages would far outweigh just writting a new simulator in Smalltalk. And they would probably be too low level for your needs in any case. You can find more suitable simulators in C, Java and similar languages.
In implementing the new JIT VM I would like to continue developing in Smalltalk using VMMaker/Slang,
Good plan!
but this implies having a processor simulation in Smalltalk to produce actual machine code for. Ideally this would be an x86 of some description (doesn't need to be bang up to date, 386 would be fine). I'd also welcome an ARM.
I wrote simulators for the 8086 and ARM2 back in 1988 and can tell you that the first is much more troublesome. Both architectures have grown more complicated since then but the x86 has done so exponentially. Just to give you an idea of how bad things are now, the RAMP people (http://ramp.eecs.berkeley.edu/) had initially planned to have a x86 implementation as one of their core options but even with all their resources they eventually had to give up and now run QEMU on Sparc cores instead!
One processor that has been implemented many times and has many formal descriptions floating around on the web is the MIPS-like academic DLX design presented in the Hennessy & Patterson textbook.
-- Jecel
Stephane Ducasse wrote:
On Nov 5, 2008, at 11:43 PM, Jecel Assumpcao Jr wrote:
I have a simulator for the 16 bit stack processor in Squeak, but I don't think it would be very interesting for you.
Where did you publish it?
http://www.merlintec.com/download/Neo.st
and a short description at
http://www.merlintec.com:8080/Hardware/Oliver
There are several issues that make this unlikely to be useful to anybody, which is why I didn't publish on SqueakSource or something like that:
- there are bugs in the hash code for the cache. I was fixing them when this project got interrupted for another but it would be better to rewrite it (too many magic constants and deeply nested expressions) and document it properly.
- there is no GUI (though you can get a simulation of the screen of the truck terminal hardware) and I was using inspectors instead.
- while simple programs run ok (even with the cache bug!) there are several memory tables that would have to be initilized and exception handling routines that would need to be written before real applications (by that I mean a Neo Smalltalk system) could be simulated. Note that I was writting the test programs directly in hex even though an assembler would be trivial to write.
-- Jecel
squeak-dev@lists.squeakfoundation.org
-
Damien Pollet -
Eliot Miranda -
Gerardo Richarte -
Gwenael Casaccio -
Igor Stasenko -
Jecel Assumpcao Jr -
stephane ducasse