It's nice!

Nit-picking, it's better to use uint8_t instead of "unsigned char". Type "char" is not always 8bits in C99 spec.

And I wonder it could separate stdio dependency from the patch. But it should be discussed by the another issue after this patch is merged.

BTW, Just for confirmation of consent.
Matz's version will be obsolete? I have no objection if it will be. Everyone (at least all committers) think so?

I think so. Current Matz version will be obsolete.

Do I understand it right that the main idea behind this new format is to make it possible to better integrate debugging support by having more flexible sections? At the same time you are shrinking the overall size by changing to a binary format? I would just like to summarise the discussion from #944 due to the reason that it seems to me that two targets are tried to been reached which are eliminate each other -> having more flexibility and at the same time making the code more compact.

This patch gave extendable and compaction.
New format can contain debugging and other informations.

@monaka I changed code for useless unsigned char
Could you review it?

I've not tested. But it looks ok except a point I commented in the diff.

I tried to build. Totally this works. But I have some comments. I'll send pull request to branch masuidrive:new_mrb_format tomorrow.

@monaka Thank you.
I'll wait for your comments.

@matz
I think dump.c move to tools/mrbc.
What do you think?

I sent pull request to masuidrive:new_mrb_format branch.

@matz Could you review it?

That image is too messy, so I made a diagram in Dia:

Download the Dia file here (use "save as" functionality of your browser):
http://www.beoran.net/eruta/uploads/diagrams/new_mrb_format.dia

Now binary mrbc dump format is available.
We can now start discussion about ROM-able ISEQ a la #880.
My idea is that iseq in the dump from mrb_dump_irep_cfunc() can be switched to native byte order.
Cross-compiling will make things difficult though.

👍

I would like to implement ROM-able ISEQ on my fork.

My plan is:
Outside:

• Use same format both for .mrb and cfunc(.c), but add endian field: 0:neutral 1: little 2: big. effective for cfunc only.
• mrbc will have new option -E<endian>, which only effective with -B option
• in build_config, user can specify endian for target like endian :big. default is nothing, which means neutral and does not refere ROM(neutral is same as current). this value is used into -E option for run mrbc.

Implementation

• mrb_dump_irep() will take new argument "endian". mrb_dump_irep_binary(*.mrb case) will pass "neutral",
  mrb_dump_irep_cfunc will pass user specified value by -E<endian>.
• load.c will read endian field, if neutral, then does not refere rom. if others, check endian on runtime, if mismatch, error(MRB_DUMP_ENDIAN_MISMATCH or something) will be returned, otherwise refer ROM directly.
• if endian field is not neutral, skip CRC calc/check.

I think same format for both *.mrb and *.c is OK for simplicity as current mruby. But endian field is meaningless for *.mrb, and CRC is meaning for *.c. I'm not sure separate representation is better or not.

Any comment?