Jose R. Valverde wrote: Thanks :) While I'm puzzeling the html document together with my open questions (not so much questions but not so easy - at least for me - i guess) to present them here (yeah, fear! ;) just some answers... I have Plexis sources and used plain SYSIII sources - yes. Sometimes I also used V7 sources because it pointed out through the recovery process that sometimes the V7 source matched more the implementation in WEGA than the SYSIII implementation was. The biggest problem here is the memory segmentation. Plexis has - as far as I understand the code - no segmentation/non-segmentation support. It only supports one memory segment like the other SYSIII implementation did (please correct me if I'm wrong - I'm far away from being a professional here). ZEUS introduced a flag in the user structure specifying if the user runs a programm in the segmented or non-segmented mode which was based on what C-compiler was used (or what ASM, PLZ/ASM, PLZ/SYS directive was set.). In the segmented mode all 128 memory segments where used, in the non segmented mode only one of those 128 segments (as far as I can remember it was always segment 63) was used. In plexis I didn't saw such logic. This creates problems when it comes to memory access in the Kernel or such things like file execution where the special s.out header has differences for segmented or non-segmented programs. the WEGA-Developer themself (I had contact to their kernel developer) just took ZEUS and wrote "some" machine-specific kernel parts new. They never had access to the ZEUS sources. Later after WEGA was in place they got access to original V7 sources and modified/added stuff in WEGA. All sources the WEGA guys used is available to me because I got access to the Development floppies (containing also firmware sources and so on... ;)) It can be clearly determined which objects are still original ZEUS objects and which where rewritten by the WEGA guys: a) the libraries LIB1 and LIB2 are storing the file modification times of the included objects. The original ZEUS objects are all dated in '83 or '84, all WEGA implementations are dated later beginning with '86 for some ASM-based objects and '88 and '89 for C-based objects. b) the original ZEUS libraries are all containing the SCCS ident string like char sys4wstr[] = "(a)[$]sys4.c Rev : 4.2 09/26/83 22:15:02"; whereas the WEGA-sources are not containing such "whatstring". This might be the case - but I just don't hope so.. I'm much interested about hearing more about this. I only knew ZEUS, even Plexis came quite late to my ears. Greetings, Oliver -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/

What happens if you use instead u.u_count = (~(-u.u_segmts[NUSEGS-1].sg_limit))<<8; That should mean the same, would avoid using a hard coded value and the compiler may optimize it to the same assembly. I hope you understand that any advice will probably be faulty as we can not check the code generated by our suggestions as you do. As long as you don't mind that, it's OK. j -- These opinions are mine and only mine. Hey man, I saw them first! José R. Valverde De nada sirve la Inteligencia Artificial cuando falta la Natural

Jose R. Valverde wrote: I'm sure. I've the man-page for lkdata() and unlk() #include <sys/lockblk.h> long lkdata (fildes, flag, lkblk); int fildes, flag; struct lockblk *lkblk; long unlk (fildes, flag, lkblk); int fildes, flag; struct lockblk *lkblk; in the eastern germany english was not teached (or very rarely) so many things - even in the world of the computers - where kept in german - so did the man pages. I can post the man-page link but your german isn't probably that good ;) http://pofo.de/cgi-bin/man.cgi?query=lkdata -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/

It probably depends on what your Solaris 8 source license says. I can't remember offhand the terms of the Solaris Foundation Source Program which provided it under non-disclosure terms, but it wouldn't surprise me if they stated that you only got access to Solaris 8, not to ancestor SV code. Your license should tell (mine is at home now) but I suspect it will be highly restricted. j

Hi Jose, Jose R. Valverde wrote: leads to: "sys2.c":305: operands of "&" have incompatible types Error in file sys2.c: Error. No assembly. I've changed it to: u.u_dirp.l = (caddr_t) (*((long *)((long)uap->linkname &0x7F00FFFF))); and this produces: ldl rr2,rr8(#4) and r2,#32512 ldl rr4,@rr2 ldl _u+78,rr4 not exactly the wanted code :( Greetings, Oliver -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/

Oliver, BTW, I am thiking more clearly now and realize I initially confused the uap struct in lock() with u_uap, although what is actually assigned is uap->linkname to u.u_dirp. When seeing the type definitions in param.h I also notice that it defines caddr_t (the type of the u.u_dirp.l side of the saddr_t union) as typedef char *caddr_t; /* pointer to kernel things */ that leads me to consider that the &0x7F00FFFF may be an additional security check to ensure that the pointer falls within valid memory space, in which case it would match the memory map. I notice that nsseg in mch.s may return %7F00 on some cases and is used in machdep.c as stseg = nsseg(u_state->s_sp); so it seems the stack uses segment 0x7F00. Then may be the & is shorthand to make sure the address pointed by the ANDed pointer falls within the stack. It would probably imply user programs have a maximum stack size of 65536 bytes as well. That may explain why some pointers are ANDed and others not. I haven't had a thorough look, but if the &0x7F00FFFF usage is consistent, then that's is an explanation that may guide source reconstruction. Does this look sensible? j -- These opinions are mine and only mine. Hey man, I saw them first! José R. Valverde De nada sirve la Inteligencia Artificial cuando falta la Natural

Dear Oliver, well, the fact that prf.c uses the anding explicitly means that it was actually used as such directly in the code. But... On Thu, 26 Jun 2008 16:52:46 +0200 Oliver Lehmann &lt;lehmann(a)ans-netz.de&gt; wrote: Let me test if I understand this: rr2 = adx rr4 = *adx s = rr4 Which is the equivalent to the code you describe in your problems page except for the @ it also would look like what's doing is s = (char *) ( (*(long *)adx) & 0x7F00FFFF; reflecting how the compiler has read the line (giving higher precedence to the * than to the &). Am I mistaken? Hence the & is done to the value pointed by adx, not to adx itself before indirecting it. That means that adx contains a pointer to a pointer instead of a pointer to unsigned int as declared, and would explain why the need for the first cast (long *), so the value pointed by adx is stored in a long not an unsigned int. I wonder why adx would not have been declared as unsigned long * directly... Then that long (which is actually a pointer) is ANDed to fall in the stack, and finally coerced to be interpreted as a char *. > > So the only thing in sys2.c's link() you wanted me to change in your > previous mail was: > u.u_dirp.l = (caddr_t) ((long *) uap->linkname & 0x7F00FFFF); > right? Tried this, and got: > "sys2.c":305: operands of "&" have incompatible types > Error in file sys2.c: Error. No assembly. My take is that whatever the original source must have been very close to my suggestion. If we assume the former interpretation then, of course in prf.c it compiles (as it is ANDing a pointer coerced to long with the constant) and here it doesn't (as it would be ANDing a long *. Why don't you try to split the assignment into various statements to reproduce the assembly and the recombine them? Like, e.g. 1: r2 = uap->linkname; /* ldl rr2,rr8(#4) */ 2: r4 = (long) r2; /* ldl rr4,rr2 */ 3: r4 &= 0x7F00FFFF; /* and rr4,#32512 */ 4: u.u_dirp.l = (caddr_t) r4; /* ldl _u+78, rr4 */ If you can get it by parts, then you can work your way back recombining with parenthesis. I suspect line (2) above will give the lead. Other possibility is some other conversion was used. I notice similar code on rdwr(), but here it is of the king ldl rrX, something ldl rr4,rrX(#some offset) and r4,#32512 (or some other value, like 61440) So, what if it was called somehow so that the compiler decided to assign the value of rr2 to an auxililary register believing there was an offset but the offset was zero? u.u_dirp.l => ((saddr_t) (uap->linkname)).l may be they first cast uap->linkname into a segmented address (as it points to user data) leading to (saddr_t) uap->linkname).l to get the segmented stack pointer that was to be fixed by the AND and then you cast it to long for the AND (long) ((saddr_t) uap->linkname).l giving u.u_dirp.l = (caddr_t) ((long) (((saddr_t) uap->linkname).l) & 0x7F00FFFF); // this might force use of an aux. variable for the 0 offset and then anding it or may be the simpler implicitly forces the code u.u_dirp = (saddr_t) (((long) uap->linkname) & 0x7F00FFFF); Another possibility is that it were coded by hand in assembler working over assembly listings generated by the compiler: on development, probably prf.c was coded early on, and then maybe they hand coded that code using prf.c as a template (reproducing the verbose now unneeded ldl rr4,rr2 line). > > I notice that nsseg in mch.s may return %7F00 on some cases and is used > > in machdep.c as stseg = nsseg(u_state->s_sp); so it seems the stack uses > > segment 0x7F00. Then may be the & is shorthand to make sure the address > > pointed by the ANDed pointer falls within the stack. It would probably > > imply user programs have a maximum stack size of 65536 bytes as well. > > > That may explain why some pointers are ANDed and others not. I haven't > > had a thorough look, but if the &0x7F00FFFF usage is consistent, then > > that's is an explanation that may guide source reconstruction. > A memory segment is 64Kbyte of size. The hardware is a bit special here. > The CPU can access the memory in a segmented and a nonsegmented mode. For > this purpose 3(!) MMUs are existing. A special MMU control logic is > implemented which can handle 3 states: > 1: segmented OS (CPU works in system mode) > The segments Code, Data and Stack are managed by MMU1. MMU2 and > MMU3 are not active > 2: userprocess not segmented (CPU works in normal-mode, segmentnumber 63) > The segments Code, Data and Stack are managed by MMU1. MMU2 and > MMU3 are not active. This is done by a special break register > 3: userprocess segmented (CPU works in normal-mode) > MMU2 and MMU3 are used to process the 128 possible memory segments > which can be Code-, Data- or Stack-Segments. MMU2 manages the > segments 0-63 and MMU3 manages the segments 64-128. The switching > between both MMUs works hardwarecontrolled in dependence of the > segmentline. Both MMUs are programmed for segment 0..63. > A colleague of mine wrote about this: > >>>>> > I've looked at your problems site and think I can imagine why the AND 0x7f00ffff > is there. Remember, the Z8000 segmentation concept is flawed the way that a segment > address can wrap around without warning. Now, at a higher level, UNIX uses a flat > address space and somewhere, this logic address needs to be translated into > physical addresses. This is done by the MMU - however, if within a pointer arithmetic > an overflow beyond the 64k boundary happens, it can spill over into the segment number > which is - you might remember at bit [30:24]. So as soon as a pointer is created by the > compiler, it is ANDed with 0x7f00 for the upper 16bits to extract the segment number and > with 0xffff for the lower 16bit address to obtain the real logic address PC. > It would be really interesting to look at the implementation of malloc for memory blocks > greater than 64K byte. My assumption is that the compiler inserts this AND on its own for > any pointer arithmetic. > <<<<< > Maybe this helps... > Greetings, Oliver > -- > Oliver Lehmann > http://www.pofo.de/ > http://wishlist.ans-netz.de/ -- These opinions are mine and only mine. Hey man, I saw them first! José R. Valverde De nada sirve la Inteligencia Artificial cuando falta la Natural

On Sun, 29 Jun 2008 10:25:23 +0200 Oliver Lehmann &lt;lehmann(a)ans-netz.de&gt; wrote: But you would still be able to see what did generate the code (barring register number). Yes, but it also does not reflect the correct usage. linkname is not an saddr_t* but an saddrt_t. And you want to assign directly the value of uap->linkname not what it points to. typedef union { caddr_t l; struct { unsigned left; unsigned right; } half; } saddr_t; /* segmented address with parts */ My fault. That's a typical beginner's mistake I made there. I'm starting to feel embarrassed of so many mistakes I'm making lately. BTW, I'm on a deadline so most probably my mind is not 100% in place so do not take me too seriously specially when dealing with complex abstract data types. That is because an saddr_t is a union. You cannot assign directly to a union (u.u_dirp), you must assign to a union member (u.u_dirp.l), but the union member is not an saddr_t, it is a caddr_t: the correct text would be u.u_dirp.l = (caddr_t) (((long) uap->linkname) & 0x7F00FFFF); which you know does not work. That is why I suggested the extra cast to see if the compiler would be misled into using an unneeded zero-offset assignment instruction to an auxiliary register. u.u_dirp.l = (caddr_t) ((long) (((saddr_t) uap->linkname).l) & 0x7F00FFFF); that should be tantamount to u.u_dirp.l = (caddrt_t) ((long) ((caddr_t) uap->linkname) & 0x7F00FFFF); where due to the long cast the initial caddr_t cast would be redundant reducing to u.u_dirp.l = (caddr_t) ((long) uap->linkname & 0x7F00FFFF); but introducing a saddr_t cast that might fool the compiler into a temporary assignment with a zero offset (the .l) into ldl rr4,rr2 And I still think that dividing the assignment into intermediate instructions and looking at the assembly might shed some light into what is going on. -- These opinions are mine and only mine. Hey man, I saw them first! José R. Valverde De nada sirve la Inteligencia Artificial cuando falta la Natural

On Mon, 30 Jun 2008 19:34:50 +0200 Oliver Lehmann &lt;lehmann(a)ans-netz.de&gt; wrote: So it means that you can reproduce (barring the stack assignments) the behavior that you describe is puzzling you by using an auxiliary variable. That is you exactly get So the problem now is to figure out how the compiler came to use an additional internal variable (maybe by playing with parenthesis) or figure out if the original coder could have sensibly used an additional variable actually. This is starting to look nasty. My bet now is the compiler is getting confused to parse the line. One thing: try with some additional parenthesis to disambiguate u.u_dirp.l = (caddr_t) ((long) (((saddr_t) (uap->linkname).l) & 0x7F00FFFF); and see if that works or the same error repeats. Then, either one of two: the original code did look that ugly, the author faced a difficult to parse expression and broke it with an auxiliary variable, saddr_t aux; aux.l = (caddr_t) uap->linkname; u.u_dirp.l = (caddr_t) ((long) aux.l & 0x7F00FFFF); or, now that I come to think of that, seeing the split example I just gave, maybe it was all the way implicitly defined _the right way_: and instead of register struct a { char *target; char *linkname; } *uap; ... u.u_dirp.l = (caddr_t)(((long)uap->linkname) & 0x7F00FFFF); /* FIXME: this is not 100% compatible */ they actually had the original code register struct a { char *target; saddr_t *linkname; } *uap; ... u.u_dirp.l = (caddr_t)(((long)uap->linkname.l & 0x7F00FFFF); which would be absolutely clean, coherent with the way u_dirp is declared and introduce a zero-offset union reference in the expression leading to the compiler assigning an additional auxiliary variable to produce the expression. j -- These opinions are mine and only mine. Hey man, I saw them first! José R. Valverde De nada sirve la Inteligencia Artificial cuando falta la Natural

On Tue, 1 Jul 2008 20:35:41 +0200 Oliver Lehmann &lt;lehmann(a)ans-netz.de&gt; wrote: That looks like the compiler is ignoring the parenthesis... So, maybe what happened was that the original author also tried several of these combinations and failed as well, and may be -as I mentioned- On Tue, 1 Jul 2008 16:21:02 +0200 "Jose R. Valverde" &lt;jrvalverde(a)cnb.csic.es&gt; wrote: or some such. j -- These opinions are mine and only mine. Hey man, I saw them first! José R. Valverde De nada sirve la Inteligencia Artificial cuando falta la Natural

This is puzzling me... so I decided to check whether I could somehow reproduce the problem here assuming your compiler derives from the one in System-III. So, I have installed System III on SIMH from the tapes in TUHS. Silly me, I didn't realize that I was using the ones for PDP-11 and so they are probably farther from the WEGA than the tapes for VAX. Still, while remaining within 16 bits, it seems like I can sort of reproduce some similar behavior on the PDP-11 System-III. If I find some spare time I will try to install SysIII on the VAX simulator as well and see if that works better. For the curious, I started off Hellwig Geisse's distro of V7 on PDP-11 http://homepages.fh-giessen.de/~hg53/pdp11-unix/ and succeeded to install mini-root. Then I had to use an intermediate V7 to restore from tape the tar archive of the full file system. After a few extra changes, I got System III apparently up and running (at least reaches single user and compiles itself). I don't know if there is any additional interest on this, but should it be I can make the UNIX System III distribution with instructions available for anybody interested. This distro comes with instructions AND a working system image, hence it is big, much bigger than Geisse's V7, but for today's standards it is a paltry 35M. j On Sun, 6 Jul 2008 18:14:19 +0200 Oliver Lehmann &lt;lehmann(a)ans-netz.de&gt; wrote: -- These opinions are mine and only mine. Hey man, I saw them first! José R. Valverde De nada sirve la Inteligencia Artificial cuando falta la Natural

Jose R. Valverde wrote: prf.c has another author than the source files I've got the problem with. prf.c was "developed" by the guys at EAW who created WEGA. Developed means here, they disassembled the ZEUS objects and created C files out of the ASM listing like I do. Probably they didn't figured out the "ldl rr4,rr2" part of the original ZEUS object (which was probably there) too and they decided that how it is done now has the same effect. So - you can say all sources which contain german text are created based on ZEUS disassembled objects so they are not "original" ZEUS. all the source files containing a "whatstring" from the version control system are files created by me by disassembling the original ZEUS objects. One interesting thing for example can be found in the WEGA-debug.c: callr _gethex and r2,#16128 ldl rr4,rr2 and r4,#32512 ldl |_stkseg+~L1+8|(fp),rr4 is the ASM code from the original object What they've tryed at EAW when writing the debug.c file was: #define UMASK 0x3f00ffffL #define KMASK 0x7f00ffffL [...] kadr = (unsigned int *)((long)(gethex() & UMASK) & KMASK); But this gets compiled into: callr _gethex and r2,#16128 ldl |_stkseg+~L1+8|(fp),rr2 which is the same because - when the AND with 16128 happend, an AND with any higher value won't change the register - so the optimizer probably decided to remove the and with 32512 - which is not removed in the original object.... A friend of mine is working on a P8000 emulator - 8Bit is kinda done, 16bit part is "in progress" - no idea how long it will take him to complete it since I have no circuit plans of the 16Bit part - only the original (good documented) Firmware Sources. When it is done and it can be released officially you can all enjoy the feeling on working with a P8000! ;) -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/