[jsa]

People have asked before "Why did those morons do it that way?" Please take that to another thread.

Humour me momentarily please. Is it a way to have data where it is needed so the 8061 can keep accepting bytes from RAM or ROM in a continuous stream instead of issuing requests for other memory addresses ? Effectively improving the Mbus efficiency ?

[decipha]

inline parameters are for common functions that modify diffrrent variables in the same way

rather than wiriting many different functions that effrctively do the same thing but with different inputs, its more efficient to write one function that modifies the inputs its given

I personally do not like them and never use them. I embed any function I need parameters for but thats a different discussion.

[mpaton]

People have asked before "Why did those morons do it that way?" Please take that to another thread.

Humour me momentarily please. Is it a way to have data where it is needed so the 8061 can keep accepting bytes from RAM or ROM in a continuous stream instead of issuing requests for other memory addresses ? Effectively improving the Mbus efficiency ?

I'm taking your question to mean why are the parameters passed inline instead of on the stack or in registers. decipha seems to have answered the question of why there are parameters.

So I'm just speculating here:
First you need some standards when you've lots of people writing code that is expected to actually work. Back in those days it had to be right before it went out, and there would (in the beginning at least) have been lots of checking before something shipped.

There's quite some evidence (by my inspection anyway) of quite a lot of standards and conventions in how things are coded. Even though some Ford countries seem to have broken some of the US standards. 'Straya for example!

There was no flash memory to update shipped code. Ford could have updated with a chip in the J3 port, but they REALLY wouldn't have wanted to.

ROM space was small, memory was expensive, so save code and data space.

High level languages were distrusted.

Execution speed doesn't seem to have been much of a concern interestingly enough.

This code would have been written using a Macro Assembler, and there would be a standard library of macros, and one of them would have been for passing parameters. New macros would take some time to validate before being approved for production use.

When the macros, and the coding conventions were written, the writers may have had a different view of the future than what actually happened.

With using the macros, the programmers may not even have seen inline parameters, just macros.
So they almost certainly didn't care about how the code looked to people doing disassembly.

That help any?

Michael

[jsa]

Yes, that helps. Thanks Mike & Mike.

[decipha]

The original ford code was written in C, I have actually seen with my own 2 a portion of the actual cbaza source code

[mpaton]

The original ford code was written in C, I have actually seen with my own 2 a portion of the actual cbaza source code

i seriously doubt that earlier Ford bins were written in C. I don't doubt that there is pseudo code posing as documentation written in C.

[sailorbob]

Early eec-iv code was hand coded in assembly. When Ford compared their assembly code to a compiled Pascal-F equivalent code they found the latter to use roughly twice as much memory and run about 60% slower. They also experimented with a mix of hand coded assembly for the coding of the strategy algorithms, real time interface and executive operating system together with their own higher level language "Ford Automotive Control Terminology" (FACT) for the tabular data and calibration data (i.e. the code that forms the background routines) but this was still slightly inferior in efficiency. There are some IEEE papers floating around that go into more detail about this.

[jsa]

3.S.3. Subroutine Linkage
Parameters are passed to subroutines in the stack. Parameters
are pushed into the stack in the order that they are
encountered in the scanning of the source text. Eight-bit
parameters (BYTES or SHORT-INTEGERS) are pushed
into the stack with the high order byte undefined. Thirty two
bit parameters (LONG-INTEGERS, DOUBLEWORDS,
and REALS) are pushed into the stack as two
16 bit values; the most significant half of the parameter
is pushed into the stack first.

So are 8061 parameters going to the stack always words ?

Link to the handbook;
http://bitsavers.informatik.uni-stuttga ... ndbook.pdf

[sailorbob]

Data pushed to and pulled from the stack is always word sized.

[tvrfan]

But remember that for inline params, the value on the stack is an ADDRESS, and that address may be odd, because opcodes have different byte sizes...
This is why the extraction of the inline params is always byte by byte.....even if the param is a word.

Having done a lot of 'C' code, the way those inline params are done in the EEC code doesn't feel like the way 'C' would do it....although I guess it's possible.
and A9L DEFINITELY has some stuff which I reckon has to be hand coded, as it violates every known principle of structured programming (like doing a JMP to a subroutine, 'C' compiler wouldn't do that kind of trick), and a (RET, Reg 0) . I'll let our learners try to figure out what that does.....

[cgrey8]

...for inline params, the value on the stack is an ADDRESS, and that address may be odd, because opcodes have different byte sizes...
This is why the extraction of the inline params is always byte by byte.....even if the param is a word...

I'm confused by this. I wasn't aware that every inline param was a pointer to where data is. I thought part of the efficiency of embedded data where an opcode would normally be would be to put the actual data there...not a pointer value to data. Is that not right? The inline data value is always a pointer? If so, that makes sense why the embedded data is always word sized since pointers are always 2-byte. I'm just wanting to make sure I interpreted this correctly.

...Having done a lot of 'C' code, the way those inline params are done in the EEC code doesn't feel like the way 'C' would do it....although I guess it's possible...

I tend to agree with you that the things yall are talking about in the assembly don't feel like things even old 80s era C compilers would've done. In today's C/C++ compilers, they have the ability to set optimization levels. When compiled for debugging, the organization of the code is very straight forward since the debugger has to be able to follow the symbol table to display what's happening during a debug session. However when optimization is turned ON, the compiler does ALL KINDS of tricks. Try single-stepping an optimized program. The program counter jumps all over the place, for-loops are completely eliminated in some cases, variables are reused for other things on the fly, down-graded to smaller sizes, or completely eliminated which completely throws most debugging software for a loop. They have a rather complex and difficult to understand bag of tricks that often are specifically catered to the processor's abilities. The same tricks widely used on an x86 are sometimes just not possible on an ARM9, 68k/Coldfire, or PowerPC due to the instruction set or architecture. I have no clue if any of the "common" things compilers do is stack manipulations. Although one of the things modern compilers have the benefit of is modern processors with look-ahead prefetching abilities and branch prediction to make pipelining possible. A lot of the tricks they do are the tricks they know will work well with the hardware optimizations. So from that standpoint, a particularly clever and beneficial trick to optimize memory access on one of these old processors could have unintended negative performance consequences when analyzed, at runtime, with what the processor actually does (or would've done with more straight-forward code). This begins to delve into the long debated CISC vs RISC. And I won't go there. But my point is, C compilers are much more methodical. And most don't think 2nd about including pad bytes to attain word alignment or including NO-OP opcodes to keep things aligned so they could safely make other other optimizations that required this and trust that hardware optimizations will actually remove the NO-Ops later in the pipeline so their only overhead was slight memory bloat. And when memory is aplenty, its a worth while tradeoff, but back in the 8061/5 era, this practice was something the assembly guys, no doubt, were going to great pains to avoid since back in the 80s and into the early 90s, memory was worth more than its weight in gold. Every byte counted and these processors had little-to-no pipelining/prefetching.

...A9L DEFINITELY has some stuff which I reckon has to be hand coded, as it violates every known principle of structured programming (like doing a JMP to a subroutine, 'C' compiler wouldn't do that kind of trick), and a (RET, Reg 0) . I'll let our learners try to figure out what that does.....

I don't understand the Return to Reg0. That's the NULL register isn't it? I'm trying to envision how doing such a thing would ever be beneficial for anything other than forcing a Watchdog Timeout. There's got to be a trick to that practice I'm missing.

[tvrfan]

...for inline params, the value on the stack is an ADDRESS, and that address may be odd, because opcodes have different byte sizes...
This is why the extraction of the inline params is always byte by byte.....even if the param is a word...

I'm confused by this. I wasn't aware that every inline param was a pointer to where data is. I thought part of the efficiency of embedded data where an opcode would normally be would be to put the actual data there...not a pointer value to data. Is that not right? The inline data value is always a pointer? If so, that makes sense why the embedded data is always word sized since pointers are always 2-byte. I'm just wanting to make sure I interpreted this correctly.

This response, and the one in the inline params thread says to me that you are missing a fundamental way that subroutines are processed by a CPU. Inline params themselves aren't always addresses (but can be), but the MECHANISM for getting them is the issue here. Example....

Code: Select all

40a8: c3,74,e2,3c       stw   R3c,[R74+e2]   Perload = R3c;                 # Volumetric Efficiency (=Load)
40ac: ef,a5,f5          call  3654           Srolav3T(Aeload,Load,ldffact);         # Rolling average
40af: 1c,02,5c,02,54,d0 #args  

I can tell you that these three inline parameters are two WORDs, followed by a (word) pointer, and they all begin on an odd boundary, because of where the opcodes happen
to be. In this case, it would be undefined/illegal to do a LDW.

I am hitting this hard because it's one of the fundamental foundation pillars...and cracking this is a big jump forwards.

[tvrfan]

...A9L DEFINITELY has some stuff which I reckon has to be hand coded, as it violates every known principle of structured programming (like doing a JMP to a subroutine, 'C' compiler wouldn't do that kind of trick), and a (RET, Reg 0) . I'll let our learners try to figure out what that does.....

I don't understand the Return to Reg0. That's the NULL register isn't it? I'm trying to envision how doing such a thing would ever be beneficial for anything other than forcing a Watchdog Timeout. There's got to be a trick to that practice I'm missing.

Again, this is a hand coded trick to do with subroutines and is a 'short cut' of a particular type, and as I read this I realise I've MESSED THIS UP !!
Oops, apologies, it should have read R0 = POP; and then a RET; (what a stupid idiot is me...) Right...OK.......ignore and carry on as if nothing happened.

Yes, R0 is a permanently NULL register, so what does that do ?

I don't want to give this away, as it's fundamental (and I've ruined my credibility now anyway......)

[cgrey8]

I get that the R0 (NULL register) is always read as 0 and will always be 0 even if you write values to it. In Linux, you get the same functionality with the NULL device (aka /dev/null). You often direct return text from programs you don't want making it to the terminal to /dev/null so nobody sees it.

But back to your point...what is it? In the tangent distraction, I'm still lost as to what you were building toward.

[jsa]

In the manuals it talks about R0 being a reference for a certain type of addressing. This goes to the nuances of op codes for CAĹL and the like.

I haven't reread it enough, to explain it off the top of my head.

[tvrfan]

Yes, R0 in usage is exactly like /dev/null. You can write to or read from it, and it will always be zero.

OK, What I was trying to say was -

In a compiler build, I find it very hard to believe it would ever JUMP to a subroutine instead of/as well as a CALL.
The R0=POP; RET; is short-cutting over a subroutine return, again not what a structured design/compiler would do.

Yet EEC bins do these things.

These tricks require some careful coding if you don't want to mess up the stack, and so I think they show low level coding, perhaps with a symbolic or macro language, but not 'C'. I have my doubts that later optimised compilers would do this, as it makes it VERY hard to keep track of the compilation.

The A9L even has a data word (= inline param) in one of its task lists (a list of subroutine addresses with data in the middle ?) No, I reckon that's done by hand.

But that's only my opinion...

[decipha]

I argue opposingly

I dont think anyone in their right mind would put a word in the middle of a vector list, therefore I would think it HAD to be the compiler

[ender11]

if I remember right method of transferring parameters: you push some regs to stack, then call the subroutine. sub does what? it pops return address, pops parameters, pushes address back, then doing it's job.
with inline parameters, sub pops rerturn address, loads parameters with slightly different style than in previous case, pushes return address back, and doing it's job.
what the difference? parameters are not beiing pushed, hence no time spent, no memory used for "push" comands. faster execution.
it's important for a small computer, like eec-iv.

[tvrfan]

A suggestion - this might be the result of MACROS in the original code.

Let's assume for now that Ford engineers used a low level language which was a bit higher than actual assembler.

There are languages around this level which are/were called macro assembler/language in 70's and beyond.
It's a long time ago, but I remember many had subroutine like statements where you could define a set of opcodes as a subroutine and then call it with (fixed) parameters.
It did relieve quite a bit of coding drudgery.... perhaps that's what Ford used ?

This was far far more basic than 'C' or any similar language, so don't compare that way.
I see there is still stuff for the Microsoft one....MASM. have a read if you're interested.

[tvrfan]

I argue opposingly

I dont think anyone in their right mind would put a word in the middle of a vector list, therefore I would think it HAD to be the compiler

Fair enough. A valid point of view. We can disagree and still be friends right ??

[decipha]

yep, I'll dance at your wedding lol