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

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)
Newer Posts
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 -