Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon.

Pages: 1-4041-8081-

Hey /prog/

Name: Anonymous 2012-03-07 3:41

improve my virtual machine

git clone https://code.google.com/p/gpvm/

Forgive my lack of documentation. This will be remidied shortly. Also, some instructions remain unimplemented, as I haven't found a use for them yet.

Also, note the absolute lack of references (int &a = b). Haskell has created the idea in my head they are not needed, but I can see them being useful and I will almost undoubtedly implement them at some point.

I look forward to sorting through your abuse to see if anyone says anything constructive.

Name: Anonymous 2012-03-07 4:17

git
stopped reading right there.

Name: Anonymous 2012-03-07 4:22

Why are there so many massive macro chunks in assembler.c? Why not inline functions?...

Name: Anonymous 2012-03-07 4:27

>>2
Not using git.

That's like not using Linux. YOU DON'T DO IT.

Name: Anonymous 2012-03-07 4:47

>>3
Did you read the comment at the top?

The reason is pure laziness. I dread maintaining that assembler but it is entirely my fault. Attempts to make a better one (Attempting to improve the current would be like going to sphagetti city to eat baked beans) have been shadowed by the more important matter of maintaining and bettering the virtual machine itself.

The assembler works. I consider that a plus.

Name: Anonymous 2012-03-07 9:23

>>src/exec.c
Why do you use a giant switch instead of dispatching at the end of each instruction handler as a tail-call? Why aren't there statically dispatched movement operations? Why do you use string-based lookups? Why do you use a cavemen-style stack instead of an x86-style stack? Why doesn't it provide support for cooperative threading? Why doesn't it provide array objects?
0/10

Name: Anonymous 2012-03-07 9:45

>>4
Eat a dick mr. imageboarder. Maybe if you stop using imageboard memes someone might take you seriously.

Name: Anonymous 2012-03-07 10:05

>>6
Downward-growing stacks considered harmful. Downward-growing stacks in a reallocatable heap considered harmful as fuck.

Name: Anonymous 2012-03-07 10:22

>>8
x86 can use upward-growing stacks. Also, you can massively over-allocate stack space and the physical memory space won't actually be used until you access it, thanks to virtual memory.

Name: Anonymous 2012-03-07 10:25

>>8
What exactly do you mean by a downward-growing stack? Does it grow like a bamboo (newer addresses appear at the root) or like a pine (newer addresses appear at the tip)?

Name: >>9 2012-03-07 10:29

>>10
All stacks allocate memory at the top. Downward-growing stacks have their top facing the zeroth memory address.

Name: Anonymous 2012-03-07 10:52

>>11
So you are saying that downward-growing stacks have their top at the bottom? IHBT.

Name: Anonymous 2012-03-07 10:54

>>12
Exactly.

Name: Anonymous 2012-03-07 11:09

>>9
x86 can use upward-growing stacks.
By using a kludge involving adding an ADD/SUB/LEA after each stack instruction. At this point, the stack pointer is a hindrance the programmer is working against. Upward-growing stacks are obviously not what >>7 meant by an "x86-style stack." What else could it mean? Using a separate stack segment?

Name: 6,9 2012-03-07 11:26

>>14
x86 can use upward-growing stacks without kludges by tickling the direction bit of the stack segment.
I was referring to the ability of performing random access on the stack and the use of enter-leave for allocation instead of push-pop.

Name: Anonymous 2012-03-07 13:57

>>15
That doesn't change the behavior of the push/pop instructions, only the limit check. Look at the Intel manual and you'll see that.

Name: Anonymous 2012-03-07 14:36

>>6
``Why do you use a giant switch instead of dispatching at the end of each instruction handler as a tail-call?''

Because it made sense. I don't know what you're suggesting, could you explain a little more clearly, or are you just trolling?

Name: Anonymous 2012-03-07 14:39

>>6
>array objects

The size of an object can be dynamically changed and you can use an ``offset pointer'' to access different parts of it. It would be trivial to implement some kind of array. Especially in a higher level language where you can abstract the details away.

Name: Anonymous 2012-03-07 15:40

I'm considering creating seperate stacks: One for general purpose use and one where the VM puts return addresses, which is not accessible to a program. THis wopuld greatly increase safety and freedom in the stack.

What does [prog][/prog] think? Good idea?

Name: Anonymous 2012-03-07 17:53

>>4

I don't use git or Linux, but that's because I am not a faggot.  I make real money in the real applications market and real business world.

Name: Anonymous 2012-03-07 18:06

>>20
That's funny, because I use git and Linux and the money I make is also real. My landlord hasn't turned any of it down. I wasn't aware there was a correlation between git, Linux and counterfeit money. Do counterfeiters counterfeit with Linux and git?

You better git back to your cubicle and churn out some more [b][i][o]ENTERPRISE[/]o[/i][/b] Java for your PHB, monkey.

Name: Anonymous 2012-03-07 18:06

Name: Anonymous 2012-03-07 18:19

>>21
Real money is measured in millions. All the money you make in your entire life will be pocket change.

Name: Anonymous 2012-03-07 18:20

>>23
And what is a million measured in?

Name: Anonymous 2012-03-07 18:23

>>23
working on MS Windows 7 in MS Visual Studio 2011 with MS Visual SourceSafe ~ millions
care to elabrote?

Name: Anonymous 2012-03-07 18:58

>>21

No, you're a hobbyist.  Sure, you can write some faggy open source bullshit that won't make you any money ever, but that doesn't mean shit to me.  In the business world, all those upvotes, karma and forum reputation points and recognition among tens of people in some sub-niche don't mean shit.  So yeah, I'll take my job in a real office than your mother's basement any day.

Name: Anonymous 2012-03-07 19:20

Your gloves have 157 charges left.

Name: Anonymous 2012-03-07 19:24

>>26
looool, if you're a programmer working in an office then you'll never be shit. The real money is in Silicon Valley where I happen to be attending a top university. I've been consulting for startups with connections to VCs who throw money around like it's confetti and when I'm ready to start my own business I'll be swimming in it.

Enjoy your praying for raises and inevitable layoff, monkeyboy.

Name: Anonymous 2012-03-08 0:15

>>17 forgive him, for he knows not what he says.

Name: 6 2012-03-08 4:13

>>17,29
#define NEXT(t) \
  if (++t->ip < t->code_size) { \
    return cycle(t); /* tail-call */ \
  } else { \
    return 0; \
  }

typedef int(*ins_f)(vm_thread_t*);

int cycle(vm_thread_t* t);

int ins_tsun(vm_thread_t* t)
{
  puts("tsun");
  NEXT(t)
}

int ins_dere(vm_thread_t* t)
{
  puts("dere");
  NEXT(t)
}

int ins_hlt(vm_thread_t* t)
{
  return 0;
}

/* inlined */
int cycle(vm_thread_t* t)
{
  static const ins_f ins[4] = {
    ins_tsun, ins_dere, ins_hlt, ins_hlt
  };
  /* tail-call and bounds checking through optimized modulo */
  return ins[t->code[t->ip] & 0x3](t);
}

This is a minimal, not executable and untested example and it's very dependent on compiler optimization but it should be the most efficient instruction dispatching design, at least on GCC for x86, mainly because it makes the loop implicit. You might want to directly write assembly in order to avoid overflowing the stack with inferior compilers.

By the way, >>1, your code doesn't react well to malformed instructions.

Name: Anonymous 2012-03-08 4:20

>>28
Your childish behaviour isn't exactly the best qualification for your glorious dreams.

Name: VIPPER 2012-03-08 4:45

>>31

Name: VIPPER 2012-03-08 4:46

>>31
Shut up! The both of you, nobody here gives a crap how much money you make. Take that shit somewhere else.

Name: Anonymous 2012-03-08 4:57

>>30

Interesting. As always, tail calls to arbitrary functions yields the most arbitrary transfers of control. You could potentially leave the cycle loop if you wanted too, transferring control to some other kind of cycle function.

Name: Anonymous 2012-03-08 4:59

>>30
Wouldn't that result in horrificly bloated binaries and slow compile times? I already have > 3KLOC and while the main loop is only a small fraction of that, nigh on abusive use of the preprocesscor like that, while maybe more efficient - Actually, the function pointer array is a brilliant idea for dispatch. I might not use all of your suggestions but that could improve my performance tenfold.

And I can see the thread struct model scaling nicely.

Also, a code integrity checker would be a welcome addition. I might implement it when I am satisfied it knows how to react well for nicely formed instructions. It is working pretty nicely but I'm battling a segfault right now. It's a sneaky bastard.

Name: Anonymous 2012-03-08 5:05

>>31
call someone childish
on /prog/

Name: Anonymous 2012-03-08 5:07

>>35
that's cool bra. There are advantages and disadvantages to any approach. One thing to keep in mind is the requirement for tail call optimization on the part of the compiler, which makes the code inherently non portable. One could compile tail recursive C to (sometimes unreadable) looping C in most cases, but doing a tail call to a function pointer might bend it beyond hope if the value of the function pointer cannot be predicted.

I think a loop with a giant switch statement inside is simple enough.

Name: >>37 2012-03-08 5:10

and checking for malformed instructions is cool and all, but if the byte code is known to be well formed, it will only slow things down.

Name: Anonymous 2012-03-08 5:27

Hey guise I implemented fibs

Yes
That's right

My VM just reached HASKELL QUALITY

In all seriousness, I like Haskell. I also like what I just achie- GPVM: Fatal: Stack Underflow

Name: OP 2012-03-09 19:52

It can now calculate the first 30 numbers in the fibonacci sequence in 48 seconds.
Yesterday, it would run for 1:3x then be killed due to excessive memory usage (It leaked, which is now fixed), and would usually make it to about the 28th number in the sequence.

Implementing the function pointer array, I expect to see a big increase in speed due to going from O(n) (switch) to O(1) (array)

Name: Anonymous 2012-03-09 21:13

>>40
Switches shouldn't be O(n).

Name: Anonymous 2012-03-09 21:26

>>41
Don't they have to compare the subject with every case? I would call that O(n), especially when deciding what an opcode is requires upwards of 60 comparisons (depending on the opcode).

Name: Anonymous 2012-03-09 21:57

>>42
you can make optimizations so the result of the comparison after treatment is the new program counter address
something like:
switch(a){
case 1:
case 2:
case 3:

where
res = a // simple example
label1:
addr_base + res
// code
// padding
label2:
addr_base + res << 1
// code
// padding
label3:
addr_base + res << 2
//code

also depending on the level of virtualization everything can be done with just masking and shifting

Name: Anonymous 2012-03-09 23:36

>>41
They aren't in D++.

Name: Anonymous 2012-03-10 0:00

>>42
No they can be implemented with a simple look up in a table and usually are. You're thinking about if tests.

Name: Anonymous 2012-03-10 0:29

>>45
Wouldn't that still involve comparisons? An array would not

Name: Anonymous 2012-03-10 1:11

>>46
Wait, never mind.

Name: Anonymous 2012-03-10 1:41

>>47
granted, implementing a switch statement necessarily trivial. But an easy and memory expensive way is to create an array of code pointers with enough slots to contain the range of case values. This is a bit psuedo codey, but:


switch(n) {
  case 1:
    printf("meep");
  case 5:
    printf("mop");
    break;
  case 13:
    printf("mope");
    break;
  default:
    printf("nope");
}

could be implemented with something like:


goto_label[] switch_labels = {
  default_entry, // 0
  case_1_entry, // 1
  default_entry, // 2
  default_entry, // 3
  default_entry, // 4
  case_5_entry, // 5
  default_entry, // 6
  default_entry, // 7
  default_entry, // 8
  default_entry, // 9
  default_entry, // 10
  default_entry, // 11
  default_entry, // 12
  case_13_entry // 13
};

if(n < 0) goto default_entry;
if(n > 13) goto default_entry;
goto switch_labels[n];
case_1_entry:
  printf("meep");
case_5_entry:
  printf("mop");
  goto switch_exit;
case_13_entry:
  printf("mope");
  goto switch_exit;
default_entry:
  printf("nope");
switch_exit:

Name: Anonymous 2012-03-10 2:14

>>46-47
Are you retarded?

Name: Anonymous 2012-03-10 2:33

>>48
Right, gotcha
>>49
No

Name: Anonymous 2012-03-10 3:05

>>50
And another way is to create a balanced binary tree and then inline it as a series of if else statements:


switch(n) {
  case 1: a();
  case 10: b();
  case 100: c();
  case 1000: d();
  case 10000: e();
  case 100000: f();
  case 1000000: g();
  default: h();
}

=> binary tree:


     _____1000_____
    /              \
   10             100000
  /  \           /      \
 1   100     10000       1000000

--> balanced if else chain:


if(n == 1000) {
  d();
} else if(n > 1000) {
  if(n == 100000) {
    f();
  } else if(n > 100000) {
    if(n == 1000000) {
      g();
    } else {
      h();
    }
  } else {  // 1000 < n < 100000
    if(n == 10000) {
      e();
    } else {
      h();
    }
  }
} else { // n < 1000
  if(n == 10) {
    b();
  } else if(n > 10) { // 10 < n < 1000
    if(n == 100) {
      c();
    } else {
      h();
    }
  } else { // n < 10
    if(n == 1) {
      a();
    } else {
      h();
    }
  }
}

In the worst case, there will be log(n) comparisons performed.

Name: Anonymous 2012-03-10 3:12

>>51

You could also just do binary search on a statically allocated array with keys and instruction offsets. I'm not sure which would be faster. Using a simple tight implementation of binary search might be more friendly on the instruction cache than this traversal of an inlined data structure.

You can also combine both approaches, where you can do binary search up until you get to a cluster of values, at which point, you can directly index into a prepared array. In this case, you would have a binary tree of arrays of instruction offsets. This can be good when the switch values cluster up in certain places, but have large gaps in between the clusters.

Another approach could be to use a statically allocated hash table. You could calculate a hashing function that perfectly hashes the used keys onto a small array. And then you only need to do a single comparison to see if the matched key matches the input. If it does not match, then the input cannot be any of the other keys, and you can go to the default case.

Name: Anonymous 2012-03-10 3:19

>>51
SBCL doesn't appear to be doing that. That is why it TWO times slower than C/C++. Lisp is shit.


(defun yoba (n)
  (declare (optimize (debug 0) (safety 0) (speed 3) (compilation-speed 0) (space 0))
           (fixnum n))
  (ecase n
    (       1        #xD)
    (      10       #xDD)
    (     100      #xDDD)
    (    1000     #xDDDD)
    (   10000    #xDDDDD)
    (  100000   #xDDDDDD)
    ( 1000000  #xDDDDDDD)
    (10000000 #xDDDDDDDD)))

(disassemble #'yoba)
; disassembly for YOBA
; 13C09ADC:       83F804           CMP EAX, 4                 ; no-arg-parsing entry point
;      ADF:       750A             JNE L1
;      AE1:       BA34000000       MOV EDX, 52
;      AE6: L0:   8BE5             MOV ESP, EBP
;      AE8:       F8               CLC
;      AE9:       5D               POP EBP
;      AEA:       C3               RET
;      AEB: L1:   83F828           CMP EAX, 40
;      AEE:       0F8483000000     JEQ L8
;      AF4:       3D90010000       CMP EAX, 400
;      AF9:       7472             JEQ L7
;      AFB:       3DA00F0000       CMP EAX, 4000
;      B00:       7461             JEQ L6
;      B02:       3D409C0000       CMP EAX, 40000
;      B07:       7453             JEQ L5
;      B09:       3D801A0600       CMP EAX, 400000
;      B0E:       7445             JEQ L4
;      B10:       3D00093D00       CMP EAX, 4000000
;      B15:       7437             JEQ L3
;      B17:       3D005A6202       CMP EAX, 40000000
;      B1C:       7508             JNE L2
;      B1E:       8B15A89AC013     MOV EDX, [#x13C09AA8]      ; 3722304989
;      B24:       EBC0             JMP L0
;      B26: L2:   8D5C24F8         LEA EBX, [ESP-8]
;      B2A:       83EC0C           SUB ESP, 12
;      B2D:       8B15AC9AC013     MOV EDX, [#x13C09AAC]      ; 'ECASE
;      B33:       8BF8             MOV EDI, EAX
;      B35:       8B35B09AC013     MOV ESI, [#x13C09AB0]      ; '(10000000
                                                              ;   1000000 ..)
;      B3B:       8B05B49AC013     MOV EAX, [#x13C09AB4]      ; #<FDEFINITION object for SB-KERNEL:CASE-FAILURE>
;      B41:       B90C000000       MOV ECX, 12
;      B46:       892B             MOV [EBX], EBP
;      B48:       8BEB             MOV EBP, EBX
;      B4A:       FF5005           CALL DWORD PTR [EAX+5]
;      B4D:       90               NOP
;      B4E: L3:   BA74777737       MOV EDX, 930576244
;      B53:       EB91             JMP L0
;      B55: L4:   BA74777703       MOV EDX, 58161012
;      B5A:       EB8A             JMP L0
;      B5C: L5:   BA74773700       MOV EDX, 3635060
;      B61:       EB83             JMP L0
;      B63: L6:   BA74770300       MOV EDX, 227188
;      B68:       E979FFFFFF       JMP L0
;      B6D: L7:   BA74370000       MOV EDX, 14196
;      B72:       E96FFFFFFF       JMP L0
;      B77: L8:   BA74030000       MOV EDX, 884
;      B7C:       E965FFFFFF       JMP L0
NIL

Name: Anonymous 2012-03-10 3:26

Clozure fails too.

Welcome to Clozure Common Lisp Version 1.7-r14925M  (DarwinX8664)!
?
(defun yoba (n)
  (declare (optimize (debug 0) (safety 0) (speed 3) (compilation-speed 0) (space 0))
           (fixnum n))
  (ecase n
    (       1        #xD)
    (      10       #xDD)
    (     100      #xDDD)
    (    1000     #xDDDD)
    (   10000    #xDDDDD)
    (  100000   #xDDDDDD)
    ( 1000000  #xDDDDDDD)
    (10000000 #xDDDDDDDD)))
YOBA
? (disassemble #'yoba)

;;; (defun yoba (n) (declare (optimize (debug 0) (safety 0) (speed 3) (compilation-speed 0) (space 0)) (
L0
     [0] (leaq (@ (:^ L0) (% rip)) (% fn))
     [7] (pushq (% rbp))
     [8] (movq (% rsp) (% rbp))
    [11] (pushq (% arg_z))
    [12] (pushq (% save0))

;;; (ecase n ( 1 #xD) ( 10 #xDD) ( 100 #xDDD) ( 1000 #xDDDD) ( 10000 #xDDDDD) ( 100000 #xDDDDDD) ( 10000
    [14] (movq (% arg_z) (% save0))
    [17] (cmpq ($ 8) (% save0))
    [21] (jne L32)
    [23] (movl ($ #x68) (% arg_z.l))
    [28] (popq (% save0))
    [30] (leaveq)
    [31] (retq)
L32
    [32] (cmpq ($ 80) (% save0))
    [36] (jne L47)
    [38] (movl ($ #x6E8) (% arg_z.l))
    [43] (popq (% save0))
    [45] (leaveq)
    [46] (retq)
L47
    [47] (cmpq ($ #x320) (% save0))
    [54] (jne L65)
    [56] (movl ($ #x6EE8) (% arg_z.l))
    [61] (popq (% save0))
    [63] (leaveq)
    [64] (retq)
L65
    [65] (cmpq ($ #x1F40) (% save0))
    [72] (jne L83)
    [74] (movl ($ #x6EEE8) (% arg_z.l))
    [79] (popq (% save0))
    [81] (leaveq)
    [82] (retq)
L83
    [83] (cmpq ($ #x13880) (% save0))
    [90] (jne L101)
    [92] (movl ($ #x6EEEE8) (% arg_z.l))
    [97] (popq (% save0))
    [99] (leaveq)
   [100] (retq)
L101
   [101] (cmpq ($ #xC3500) (% save0))
   [108] (jne L119)
   [110] (movl ($ #x6EEEEE8) (% arg_z.l))
   [115] (popq (% save0))
   [117] (leaveq)
   [118] (retq)
L119
   [119] (cmpq ($ #x7A1200) (% save0))
   [126] (jne L137)
   [128] (movl ($ #x6EEEEEE8) (% arg_z.l))
   [133] (popq (% save0))
   [135] (leaveq)
   [136] (retq)
L137
   [137] (cmpq ($ #x4C4B400) (% save0))
   [144] (jne L160)
   [146] (movq ($ #x6EEEEEEE8) (% arg_z))
   [156] (popq (% save0))
   [158] (leaveq)
   [159] (retq)
L160
   [160] (movl ($ #x4E8) (% arg_x.l))
   [166] (movq (% save0) (% arg_y))
   [169] (movq (@ '(MEMBER 1 10 100 1000 10000 100000 1000000 10000000) (% fn)) (% arg_z))
   [176] (movl ($ 24) (% nargs))
   [181] (nop)
   [182] (callq (@ .SPKSIGNALERR))
   [189] (leaq (@ (:^ L0) (% rip)) (% fn))
   [196] (movl ($ #x1300B) (% arg_z.l))
   [201] (popq (% save0))
   [203] (leaveq)
   [204] (retq)
NIL

Name: Anonymous 2012-03-10 3:38

Hey /prog/

Improve my dubs

Name: Anonymous 2012-03-10 3:45

>>55
Can't. They're too beautiful.

You selfish bastard.

Name: Anonymous 2012-03-10 3:55

AllegroCL has IDE, but can't optimize a switch.

$ ./alisp
[1] CL-USER(1): (defun yoba (n)
  (declare (optimize (debug 0) (safety 0) (speed 3) (compilation-speed 0) (space 0))
           (fixnum n))
  (ecase n
    (       1        #xD)
    (      10       #xDD)
    (     100      #xDDD)
    (    1000     #xDDDD)
    (   10000    #xDDDDD)
    (  100000   #xDDDDDD)
    ( 1000000  #xDDDDDDD)
    (10000000 #xDDDDDDDD)))
YOBA
[Current process: Initial Lisp Listener]
[1] CL-USER(2): (disassemble #'yoba)
;; disassembly of #<Function (:ANONYMOUS-LAMBDA 0) @ #x2060bf92>
;; formals: N
;; constant vector:
0: 3722304989
1: (MEMBER 1 10 100 1000 10000 100000 1000000 10000000)
2: (1 10 100 1000 10000 100000 1000000 10000000)
3: EXCL::.CASE-FAILURE

;; code start: #x2060becc:
   0: 55             pushl    ebp
   1: 8b ec          movl    ebp,esp
   3: 83 ec 48       subl    esp,$72
   6: 89 75 fc       movl    [ebp-4],esi
   9: 89 5d e4       movl    [ebp-28],ebx
  12: 83 f8 04       cmpl    eax,$4
  15: 75 0b          jnz    28
  17: b8 34 00 00 00 movl    eax,$52     ; 13
  22: f8             clc
  23: c9             leave
  24: 8b 75 fc       movl    esi,[ebp-4]
  27: c3             ret
  28: 83 f8 28       cmpl    eax,$40
  31: 75 08          jnz    41
  33: b8 74 03 00 00 movl    eax,$884    ; 221
  38: f8             clc
  39: eb ee          jmp    23
  41: 3d 90 01 00 00 cmpl    eax,$400    ; 100
  46: 75 08          jnz    56
  48: b8 74 37 00 00 movl    eax,$14196  ; 3549
  53: f8             clc
  54: eb df          jmp    23
  56: 3d a0 0f 00 00 cmpl    eax,$4000   ; 1000
  61: 75 08          jnz    71
  63: b8 74 77 03 00 movl    eax,$227188 ; 56797
  68: f8             clc
  69: eb d0          jmp    23
  71: 3d 40 9c 00 00 cmpl    eax,$40000  ; 10000
  76: 75 08          jnz    86
  78: b8 74 77 37 00 movl    eax,$3635060       ; 908765
  83: f8             clc
  84: eb c1          jmp    23
  86: 3d 80 1a 06 00 cmpl    eax,$400000 ; 100000
  91: 75 08          jnz    101
  93: b8 74 77 77 03 movl    eax,$58161012      ; 14540253
  98: f8             clc
  99: eb b2          jmp    23
 101: 3d 00 09 3d 00 cmpl    eax,$4000000       ; 1000000
 106: 75 08          jnz    116
 108: b8 74 77 77 37 movl    eax,$930576244     ; 232644061
 113: f8             clc
 114: eb a3          jmp    23
 116: 3d 00 5a 62 02 cmpl    eax,$40000000      ; 10000000
 121: 75 06          jnz    129
 123: 8b 46 12       movl    eax,[esi+18]       ; 3722304989
 126: f8             clc
 127: eb 96          jmp    23
 129: 8b d0          movl    edx,eax
 131: 8b 87 5f fc ff movl    eax,[edi-929]      ; ECASE
      ff
 137: 83 c4 10       addl    esp,$16
 140: ff 76 1a       pushl    [esi+26]    ; (1
                                               10
                                               100
                                               1000
                                               10000
                                               100000
                                               1000000
                                               10000000)
 143: ff 76 16       pushl    [esi+22]    ; (MEMBER
                                               1
                                               10
                                               100
                                               1000
                                               10000
                                               100000
                                               1000000
                                               10000000)
 146: 52             pushl    edx
 147: 50             pushl    eax
 148: 8b 5e 1e       movl    ebx,[esi+30]       ; EXCL::.CASE-FAILURE
 151: b1 04          movb    cl,$4
 153: ff d7          call    *edi
 155: e9 77 ff ff ff jmp    23
[Current process: Initial Lisp Listener]
[1] CL-USER(3):

Name: Anonymous 2012-03-10 4:08

Okay. New problem. How do I run C library functions? Will I need to read an ELF file and set EIP to the requested function?

Name: Anonymous 2012-03-10 4:20

>>58
dlopen.

Name: Anonymous 2012-03-10 4:26

>>59
Thanks, bro. My Google fu is tired from overuse.

Name: Anonymous 2012-03-10 8:34

>>53-54,57

That's kind of sad. It's not like this is very difficult to do or anything. It's just lazyness to use a naive order n if else chain.

>>55 can't.

Name: Anonymous 2012-03-10 9:13

>>33
To make tons of money you need boundless chutzpah, a Jewish mother and connections in chasidic world. That is all.

Name: >>61 2012-03-10 14:53

although one could write a macro in lisp to translate the switch statements to a balanced if else chains. If you wanted to involve something akin to a statically allocated look up table, you'd probably need to have the macro define a global array and reference it in the generated code.

Name: Anonymous 2012-03-10 15:19

>>56,61
Don't encourage the IMAGEBOARD RETARDS

Name: Anonymous 2012-03-12 5:55

>>66
WHOA THANKS FOR THE DUBS THEY'RE SO HOT I CAME SO HARD MY DICK SPLIT OPEN AND WASPS FLEW OUT AND STUNG MY MOM 9/11

Name: Anonymous 2012-03-12 6:01

Check my dubs

Name: Fuck off, !Ep8pui8Vw2 2012-03-14 10:39

>>64
Fuck off, ``faggot''.

Name: Anonymous 2012-03-15 5:44

Hey /prog/, can anyone see what I broke? A bug is driving me insane and the fibs example (as/fibs) isn't working.

hulp

Name: Anonymous 2012-03-15 5:51

What exactly is happening?

Name: Anonymous 2012-03-15 7:21

What is the point of this project?
What will it do better than jre?

Name: Anonymous 2012-03-15 7:40

>>70
What is the point of this project?
Experimenting with fibs.
What will it do better than jre?
Running fibs.

Name: Anonymous 2012-03-15 8:40

google
I stopped reading there.

Name: Anonymous 2012-03-16 23:35

>>70
What is the point of this project?
Try reading the docs
What will it do better than jre?
Not be bloated, overly complex or spam stderr.

Is anyone up for helping testing? I currently only know this will compile on my computer. If anyone's willing to type a few lines into their terminal I'll be grateful

Name: >>73 2012-03-16 23:42

Also,
What will it do better than jre?
Not target a single paradigm, therefore crippling any other paradigm despite how much a compiler writer would want to use it because of it's support, speed and maturity.

Name: jerome 2012-03-17 0:35

>>74
did you write this in couple all-nighters?
and now you are aiming for a quick bugfix?

Name: Anonymous 2012-03-17 1:21

>>75
No and wut

Name: Anonymous 2012-03-17 1:27

``absolute lack of references''
no 3-operand instructions
no exceptions
unsafe push/call mechanism with no protection for the return address or way to determine the argument count
only two data types (4-byte integer and float)
This VM is shit. Try posting it on esolangs.org, in the category ``Joke Languages''.
``Not target a single paradigm''
IHBT

Name: Anonymous 2012-03-17 1:43

>>77
``absolute lack of references''
For now.
no 3-operand instructions
I'm implementing one right now, which calls object file functions.
unsafe push/call mechanism with no protection for the return address or way to determine the argument count
The return address is on a different stack from normal stack data. It's impossible to harm it.
only two data types (4-byte integer and float)
Actually, it's typeless. THe only indication of how the VM should tread data is it's size and the instruction beign executed. (ADDF as opposed to ADD).
This VM is shit. Try posting it on esolangs.org, in the category ``Joke Languages''.
I don't agree. Also, I'd rather not. Especially considering this isn't a language. And I do enjoy the esolags website.
``Not target a single paradigm''
That's the point.

Name: Anonymous 2012-03-17 3:06

So wait...




how do i actually use this with some language? like limbo?

Name: Anonymous 2012-03-17 22:19

bump

Name: Anonymous 2012-03-17 22:38

>>79
You'd need a compiler. Right now, the instruction set and VM itself arr going through puberty in a massive way. If you're interested I'd recommended helping with the development over using it right now. Many features don't exist yet and many are changing, so a compiler could easily and quickly become obsolete.

Name: Anonymous 2012-03-17 22:40

>>81
I'll write a scheme compiler for your virtual machine in scheme.

Name: Anonymous 2012-03-17 23:04

>>82
Great! I'll need to spend a while on making comprehensive docs

Name: Anonymous 2012-03-17 23:14

>>82
scheme compiler
It can't even do tail calls or longjmp.

Name: Anonymous 2012-03-17 23:25

It is now possible to call object file functions with the lof (Load object file), cof (Call objectfile function) and cofr (call object file function that returns).

Currently only possibly on x86 as it requeres some asm.

Name: Anonymous 2012-03-17 23:26

>>83
take your time and don't worry. I don't mind reading undocumented code.

Name: Anonymous 2012-03-17 23:29

http://llvm.org/
Why would anyone choose this over LLVM?

Name: Anonymous 2012-03-17 23:33

>>87
Because llvm is a Compiler Infrastructure

Name: Anonymous 2012-03-17 23:46

>>40
It can now calculate the first 30 numbers in the fibonacci sequence in 48 seconds.
It's all an elaborate troll.

Name: Anonymous 2012-03-17 23:52

>>89
That kinda impressed my at first, considering how it would take about 2 minuites beforehand. Also, I was using the recursive method. Using the iterative algorithm is takes about 0.021s.

Name: Anonymous 2012-03-18 6:33

I included a tiny, Haskell written compiler for a typeless, functionless RPN language in the repo. it can be extended to be an interpreter by adding the line system $ "gpvm " ++ outFile to the end (before return () of course)

Name: Anonymous 2012-03-18 12:29

>>87
It's easier to study this because it has a much smaller scope. LLVM is certainly excellent for what it does but it's otherwise a massive beast of a codebase to learn from.

Name: Anonymous 2012-03-18 23:55

>>40
How the fuck did you manage for it take that long? Even Ruby isn't that fucking slow.

Name: Anonymous 2012-03-25 0:26

New assembler
I apologize for being a novice at Haskell

>>93
no experience with MREs
Python was slower than this when it was new.

Name: Anonymous 2012-03-25 1:30

>>93
Because he's (I hope) a troll. No way could someone code that badly that it runs out of memory after 28 Fibonacci numbers unless they malloc(100000000) for each integer, even with ``memory leaks''. No way could someone take 48 seconds to calculate the first 30 numbers in the Fibonacci sequence unless they added sleep(1) for each level of recursion. These are 32-bit integers, not bignums.
>>40
Yesterday, it would run for 1:3x then be killed due to excessive memory usage (It leaked, which is now fixed), and would usually make it to about the 28th number in the sequence.
For reference: 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, 233, 377, 610, 987, 1597, 2584, 4181, 6765, 10946, 17711, 28657, 46368, 75025, 121393, 196418, 317811
What machine are you running this interpreter on? Hopefully it's something like a Commodore 64, but even an interpreter written in C64 BASIC would be faster than this VM.
Also, IHBT.

Name: Anonymous 2012-03-25 1:36

>>95
go flip another patty you uneducated bitch.

Name: Anonymous 2012-03-25 1:38

>>96
Your VM is a slow piece of shit. My grandma can calculate Fibs faster than this with pen and paper.

Name: Anonymous 2012-03-25 2:09

>>97
To be honest that's not fair, your grandmother has a very advanced instruction set and implicit memoization so she doesn't recalculate the numbers.

Name: Anonymous 2012-03-25 3:22

C>>99

Name: Anonymous 2012-03-25 8:30

>>99
nice dubs bro
Don't change these.
Name: Email:
Entire Thread Thread List
All trademarks and copyrights on this site are owned by their respective parties. All comments and posts are the responsibility of their own posters.
- Tinychan + 2ch Mode -