360trev
Full Member
Karma: +68/-2
 Offline
Posts: 235
|
 |
« on: September 18, 2018, 03:09:32 AM »
|
|
|
Anyone interested? I know some people think its a dead platform but hey I plan to keep my ME7.3H4 equipped car for many more years to come  ... Anyway after doing all the usual searching for building C-Code for C167's, e.g looking at Tasking, etc. I found VBCC, VASM, VLINK compiler, assembler and linker. Its still maintained and seems like a pretty neat and simple to understand (compact) compiler project. I built them from source code and they worked right out of the box... Whats more it supports full set of extended instruction set of the C167 as used in ME7.3's. Since its a very compact compiler with full source-code and very easy to build from source-code without any issues. This has got me thinking... I could build a feature for my ME7RomTool tool which finds empty space (simply finds 0xff's... ) and does automated compiling/patching/inserting of C-object code directly into your rom files. I've just been doing an exact 're-location of final ROM-checksums' exercise so that I have a full 32kbytes of free unused space available on Ferrari ME7's. Now if I integrate VBCC and VASM (don't require vlink as I will assemble to absolute addresses and if possible generate position independant code). I could add a feature to compile C code from a given folder and automatically patch it into any function we want. Either as a direct replacement or inline then calling original function. E.g. This is pretty easy to do since I know the location of well known functions such as Main Rom Sum for example it could write an automated patcher to jump directly to your own C-code which would give you the ability to extend/replace/patch any existing function that we've identified in a given rom and then at the end return. The result is we could begin to re-write (using the PDF already available on here) inidividual functions until we have done all the important functions we may wish to customise in C. I like the idea of this since it would allow a lot more innovation if all of the plumming was done to make it easy for C developers to write code... I've now identified over 3,000 variables / table (over 350 tables!) in my own Ferrari rom which I could export for use by the C source-codes so it could pretty much do anything you want... Would anyone use it? |
|
|
|
|
Logged
|
|
|
|
fknbrkn
Hero Member
Karma: +186/-24
Offline
Posts: 1456
mk4 1.8T AUM
|
|
« Reply #1 on: September 18, 2018, 04:34:02 AM »
|
|
|
Why not asm?
|
|
|
|
|
Logged
|
|
|
|
|
woj
|
|
« Reply #2 on: September 18, 2018, 05:15:35 AM »
|
|
|
Why not asm?
A question that is pressing me too I do everything in ASM and the only thing that bothers is me is doing long integer arithmetic. By long I mean mere 32bits, but that's long for C167/ST10. The effect is that I simply try to avoid it (so far managed good). For some things there are OS routines that aslo handle overflow, but for some you are on your own. Another issue is that when the flow control in your code becomes non trivial ("and" or "or" cascades, switch-case, fancy loops) it gets a bit tedious to sort out, much easier in C. But I like the idea, if done properly. I have something of exactly the same sort - an ST10 macro assembler hacked quickly in Java / ANTLR with hooks / directives to patch the bin file directly (or produce S19 file for TunerPro). It still has some possibilities for improvements and further automation (for example, discovering which addresses have to be extp-ed/exts-ed before use), but so far works for my projects. |
|
|
|
|
Logged
|
|
|
|
360trev
Full Member
Karma: +68/-2
Offline
Posts: 235
|
|
« Reply #3 on: September 18, 2018, 05:24:14 AM »
|
|
|
Why not asm?
Ofcous I will support injection of assemby too, since in essnce the C is compiled/translated first into Assembly anyway and then assembled (vasm) into machine code. I used to write assembly (for over a decade) including some really big apps too back in the early 90's, so very well versed in it but its not exactly portable these days and most skilled developers interested I assumed would be more willing to do some cool stuff in a higher level language like C (although these days people think of C as a low level, sort of assembly language, hahah). Also since Bosch wrote the original ME7 code in C I was thinking this would be a way to recover the features in such a way that we could re-use the same code on newer architectures such as the TriCore's cross compiled.... |
|
|
|
|
Logged
|
|
|
|
360trev
Full Member
Karma: +68/-2
Offline
Posts: 235
|
|
« Reply #4 on: September 18, 2018, 05:29:11 AM »
|
|
|
A question that is pressing me too I do everything in ASM and the only thing that bothers is me is doing long integer arithmetic. By long I mean mere 32bits, but that's long for C167/ST10. The effect is that I simply try to avoid it (so far managed good). For some things there are OS routines that aslo handle overflow, but for some you are on your own. Another issue is that when the flow control in your code becomes non trivial ("and" or "or" cascades, switch-case, fancy loops) it gets a bit tedious to sort out, much easier in C. But I like the idea, if done properly. I have something of exactly the same sort - an ST10 macro assembler hacked quickly in Java / ANTLR with hooks / directives to patch the bin file directly (or produce S19 file for TunerPro). It still has some possibilities for improvements and further automation (for example, discovering which addresses have to be extp-ed/exts-ed before use), but so far works for my projects. C is very powerful (and portable) language thats stood the test of time. If you have a decent optimizing compiler then it can do a very good job of producing fast code, never as good as handcrafted assembly (despite what people may tell you these days I always used to outperform any C compiler in speed terms by about x2 and most of the a lot more), however having said all of that, the idea of using C to manipulate the variables and access maps just makes it a lot more accessible to many more developers than hand crafted C16x assembly! Also if its automated you don't need all of the 'geeky' understanding of C16x architecture specific segmentation/paging knowledge before you can actively adjust the algorithms and add in new features... -T |
|
|
|
|
Logged
|
|
|
|
|
woj
|
|
« Reply #5 on: September 18, 2018, 05:43:30 AM »
|
|
|
It's just that you also need to take care of this couple of assembly instructions that you violate to insert your patching code, for this you will need a mixture of assembly and C functionality. That's what I meant by "if done properly" remark - make a nice clean interface to sort all this out and I am in |
|
|
|
|
Logged
|
|
|
|
fknbrkn
Hero Member
Karma: +186/-24
Offline
Posts: 1456
mk4 1.8T AUM
|
|
« Reply #6 on: September 18, 2018, 06:14:17 AM »
|
|
|
Well i cant say anything about st10 or tricore stuff
But in fact of working with c167 youre limited of proc usage
In my case multimap / some can-bus stuff and so on increases cpu usage from ~60 to 80%
Take a look at the factory code and youve seen many garbage like moving between registers and memorys etc.
But ofcourse its all depending of compiler
|
|
|
|
|
Logged
|
|
|
|
360trev
Full Member
Karma: +68/-2
Offline
Posts: 235
|
|
« Reply #7 on: September 18, 2018, 06:39:27 AM »
|
|
|
Well here's a very simple C example of the code generation from vbcc... /*
* test of c...
*/
void test(char *dst, char *src, int len)
{
int i;
for(i=0;i<len;i++)
{
*(dst+i) = *(src+i);
}
}
static char in1[] = { "Hello Nefmoto!" };
static char in2[] = { "Hello World!" };
static char in3[] = { "Hello Testing" };
int test2(int va)
{
char out[16];
int result = 0;
switch(va)
{
case 0:
test(out, in1, sizeof(in1) );
result = 1111;
break;
case 1:
test(out, in2, sizeof(in2) );
result = 2222;
break;
case 2:
test(out, in3, sizeof(in3) );
result = 3333;
break;
default:
test(out, in1, sizeof(in1) );
result = 4444;
break;
}
return result;
}
and here's the generated output.. using the -tasking compiler option... $EXTEND
$MODEL(SMALL)
SCODE SECTION CODE WORD PUBLIC 'CPROGRAM'
public _test
_test proc far
sub R0,#8
mov [R0],R12
mov [R0+#2],R13
mov [R0+#4],R14
mov R10,#0
mov [R0+#6],R10
jmpr cc_uc,l3
l2:
mov R2,[R0+#2]
mov R1,[R0+#6]
add R2,R1
mov R3,[R0]
mov R1,[R0+#6]
add R3,R1
movb [R3],[R2]
l5:
mov R10,[R0+#6]
add R10,#1
mov [R0+#6],R10
l3:
mov R10,[R0+#6]
mov R1,[R0+#4]
cmp R10,R1
jmpr cc_slt,l2
l4:
l1:
add R0,#8
rets
_test endp
public _test2
_test2 proc far
sub R0,#20
mov [R0],R12
mov R10,#0
mov [R0+#18],R10
mov R15,[R0]
jmpr cc_z,l11
cmp R15,#1
jmpr cc_z,l12
cmp R15,#2
jmpr cc_z,l13
jmpr cc_uc,l14
l11:
mov R14,#15
mov R13,#DPPX:l6
mov R2,R0
add R2,#2
mov R12,R2
calls _test
mov R10,#1111
mov [R0+#18],R10
jmpr cc_uc,l10
l12:
mov R14,#13
mov R13,#DPPX:l7
mov R2,R0
add R2,#2
mov R12,R2
calls _test
mov R10,#2222
mov [R0+#18],R10
jmpr cc_uc,l10
l13:
mov R14,#14
mov R13,#DPPX:l8
mov R2,R0
add R2,#2
mov R12,R2
calls _test
mov R10,#3333
mov [R0+#18],R10
jmpr cc_uc,l10
l14:
mov R14,#15
mov R13,#DPPX:l6
mov R2,R0
add R2,#2
mov R12,R2
calls _test
mov R10,#4444
mov [R0+#18],R10
l10:
mov R4,[R0+#18]
l9:
add R0,#20
rets
_test2 endp
SCODE ends
NDATA SECTION LDAT WORD PUBLIC
l6 label word
db 72
db 101
db 108
db 108
db 111
db 32
db 78
db 101
db 102
db 109
db 111
db 116
db 111
db 33
db 0
l7 label word
db 72
db 101
db 108
db 108
db 111
db 32
db 87
db 111
db 114
db 108
db 100
db 33
db 0
l8 label word
db 72
db 101
db 108
db 108
db 111
db 32
db 84
db 101
db 115
db 116
db 105
db 110
db 103
db 0
NDATA ends
REGDEF R0-R15
end
|
|
|
|
|
Logged
|
|
|
|
|
woj
|
|
« Reply #8 on: September 18, 2018, 06:48:41 AM »
|
|
|
In my case multimap / some can-bus stuff and so on increases cpu usage from ~60 to 80%
How did you measure that? |
|
|
|
|
Logged
|
|
|
|
flamy
Full Member
Karma: +6/-0
Offline
Posts: 56
|
|
« Reply #9 on: September 25, 2018, 06:47:37 AM »
|
|
|
How did you measure that?
If I remember right, perffilt_w should Do that for you. |
|
|
|
|
Logged
|
|
|
|
|
woj
|
|
« Reply #10 on: September 25, 2018, 01:52:29 PM »
|
|
|
Thanks, I can now see in the code that the ECU collects timing figures at the end of each cyclic execution loop, just don't see yet which is the % figure, any hints on locating it?
|
|
|
|
|
Logged
|
|
|
|
|
