@DaveP
That's a nice "pipe dream" that's unlikely to lead anywhere. For one thing, I don't think OS4 performs the same on the existing variety of hardware. Wait until your SAM arrives and you may see what I mean. You will probably find yourself scratching your head and saying "gee, it didn't do that on my A1" or visa-versa. We had to have 2 different Quickfixes for SAM & A1 systems. Imagine the complications if the target hardware diverges even further. Your ideas make for interresting speculation but are unlikely to become a reality.

@ice2642
Quote:
I'm not sure where you quoted that info from but your workaround might be worth a try if I knew how to accomplish it. How do I make the system think that the last 256 bytes are absent?

@rwo
Quote:
Does it crash in "cc1"? That's where all my crashes occur. If you want to be able to compile, try the previous public OS4 SDK. When I replace the gcc directory in the current SDK with the gcc directory from the previous SDK, I can compile start-to-finish without crashes.

@Snuffy
Quote:
In the end, I may need to send it back to then for testing but I want to be sure it's absolutely necessary first. At this point I think we have gotten the attention of ACube & Hyperion and we'll see if some of these problems get worked out through software updates. The Quickfix did cure my worst graphics corruption problems so I'm still unsure as to the cause of other problems. Shipping a computer system or board across the Atlantic ocean could result in damage to the board, so I consider it a last resort.

As far as this topic is concerned, several others who are apparently using the standard SAM440ep also appear to be having compiler problems. I suspect that the compiler problems may be curable in software if we get the right persons attention on the issue.

@jahc
SAM Flex 800MHZ + 1GB memory.
Time taken: 00:02:55 saved to RAM:

Same system with WBStartup programs disabled.
Time taken: 00:02:51 saved to RAM:

@Slayer
I haven't been able to find any large sources on OS4Depot that will compile without hunting down some includes or tinkering with the makefile/sources. Some smaller sources like AmiSounded seem to compile without a crash. I check out the sources for MuiBase from SourceForge and made it about 95% through the compile before cc1 crashed. So far it crashes for me with the YAM, Jabberwocky & MUIBase sources. Can you check out YAM or MUIBase and try compiling those. YAM seems to crash cc1 most reliably.

@Snuffy
Quote:
What's your point? All I can say is the the problems I've encountered are certainly sucking the enthusiasm out of me.
Quote:
I'm not sure what they think but they seem to be saying that if Debian works then there is nothing wrong with the hardware.

@Slayer
Mainly I've been testing with sources that I've kept on my system for a long time. I've been testing with the current YAM sources from the SVN repository at SourceForge and the Jabberwocky sources from SourceForge CVS repository. To compile current YAM you will need to install newer "Flex" from OS4Depot.net but Jabberwocky might need some unusual Includes that you may not have installed. This evening I will D/L some large sources from OS4Depot that might be easier for others to try also. I'll let you know what I find so you can try that if you don't have access to the other sources I mentioned.

@broadblues
Quote:
Yes. You're right. After my original most I tried reassigning SOBJS: to an empty directory and ran the compiler. It works normally other than the cc1 crashes. I also tried the compiler with 512MB again instead of 1GB but that doesn't help. I wonder if GCC or CC1 could be using processor specific instructions that are different or don't exist on the SAM processor. Since nobody else with a SAM Flex has chimed in with a confirmation of this problem, it's hard to tell if it's just my system or a general SAM problem. I'm hoping one of the devs will take a look at the issue since I'd rather be compiling with the latest SDK.

@Raziel
Quote:
I may try 512MB again. I noticed when I applied the Quickfix that there are SOBJS for GCC. Considering other problems occuring with different amounts of memory installed in A1 and SAM, I wonder if the dynamic linking could be affected by the memory map?
I have tried one more thing since starting this topic and it works. If I replace the "gcc" directory in the latest SDK with the "gcc" directory from the previous SDK the compile works start to finish every time. That would seem to indicate that the crash is related to the current GCC installation and not some hardware problem on my SAM. As I suggested, I'm suspicious of the SOBJS. They were eliminated from recent OWB versions for a reason I suspect. I would still like to get the latest SDK working on my SAM though.

@broadblues
Quote:
No. Somtimes it crashes after compiling 3 files, other times it might make it as far as a dozen files before crashing. So far it occurs with any large program I've tried to compile so the source code doesn't seem to make any difference.

@Varthall
I tried your huge stack suggestion. It doesn't seem to make any difference. Hopefully someone will point me in the right direction so I can get back to using my computer instead of debugging it.

@Varthall
I use 400000 stack on my ?A1 and have been using 800000 on the SAM Flex. I think 10000000 seems excessive, but I'll give it a try and let you know if it changes anything.

Today I discovered that I can't compile large programs on my SAM FLex (800 MX) with the latest public OS4 SDK. After some files are compiled, cc1 crashes with an ISI error and I have to reboot. The cc1 module crashed 7 times while I was compiling YAM and 3 times while I was compiling Jabberwocky. Here are some of the unsuccessful changes I have tried:
Reinstalled the SDK from the archive on an SFS/2 and SFS/0 partition.
Booted with the OS 4.1 CD to see if the Quickfix was the problem.
Tried compiling with the sources in a ram: directory.
Tried compiling with the SDK installed in ram:
Tried compiling with only 512MB memory installed in SAM Flex.
Switched to older versions of "make" and "sh".

Can anyone else with an 800MZ SAM Flex compile large programs successfully? Does anyone have additional suggestions for changes I can try to fix my compile problem. I'm no programming expert, but I've been compiling programs with OS4 for a couple of years and never encountered problems as serious as this.

@Elwood
I spoke too soon. The graphics corruption on screens and windows may have been fixed by the Hyperion Quickfix but now I have massive graphics corruption on the OS4 splash window if I boot from the preboot screen (The one that opens if you hold down the Help (Scroll Lock) key during a reboot).

@Elwood
The quickfix appears to have fixed my 800Mz SAM Flex 1GB graphics corruption problems. I don't see the random small black dots in the display now. It's too early to tell what else may be improved.

@Hans
Quote:
I agree as far as small variables are concerned. Unfortunately, many (most?) programs store their entire set of prefs files in SYS:Prefs/env-archive and they don't really need to be in ENV: if you don't use those programs frequently. Since I'm apparently not going to convince anyone that the current OS 4.x ENV handling should be changed I won't beat this dead horse any longer.

@abalaban
Actually, I think you can get a good indication of whether env-handler is maintaining a list or copying the files. Run Snoopy with all options activated and then request a variable that isn't listed in ENV: (In a shell enter something like "getenv xxyyzz). You will see in the Snoopy output that ENV looks for the variable in ENVARC:. Close Snoopy and reassign ENVARC: to an empty directory. Request a variable that is listed in ENV: (like Charset or Language) or copy a larger prefs file like "OpenURL.prefs" to ram: (copy ENV:OpenUrl.prefs TO ram:). If ENVARC: is assigned to an empty directory, the variable that was obtained or the file that was copied must have actually existed in ENV:.

OS4 ENV is not some magical mysterious black box; it's an AmigaDOS DEVICE with a custom filesystem handled by env-handler that responds to AmigaDOS commands like other DOS devices. Consider the case of programs that place prefs in ENV: when you selet "Use" instead of "Save". Obviously, those prefs must be stored in ENV: since they are usually different than the saved prefs in ENVARC:.

In theory, Hans is probably right when he states that it's more effecient to have small variables readily accessible in ENV:. I don't think that the original AmigaOS authors ever envisioned that so many programs would be storing their entire prefs settings in the environment (ENV:). However, that's what has happened. An extreme example is SuperView witch stores 237 variables and 5 sub-directories in env-archive (ENVARC:). If you own every commercial, shareware and freeware program released for Amiga and have saved prefs for them all, your SYS:Prefs/env-archive directory would probably be larger than the rest of your SYS: partition combined. That's why happyenv and env-handler were written; to allow programs access to their prefs without loading the entire env-archive directory into memory (ram:env) at boot time. The (public) OS4 env-handler no longer serves that purpose if it copies all the env-archive files to ENV: during a boot.

You could argue that programs shouldn't be storing large prefs files in the environment (ENV:) and I would agree. At most they should be storing a variable that points to the location of required files and prefs. In fact, I like programs that do it that way because I can relocate the files to anywhere I want.

@Hans
That's strange. The env-handler.kmod on my SAM is exactly the same size as the one in my ?A1 and has the same version numer with a version date of 12/30/2006. It doesn't exibit the behavior I so desperately want. Is this another case of updates that were supposed to be included with a release but actually weren't?? Maybe we've been comparing apples and oranges.

@Hans
If you want an idea of how ENV: is supposed to work you can try this on a spare boot partition:

1. Backup your boot partition or use a spare one.
2. Clone the SYS:Prefs/Env-Archive as "SYS:Prefs/env-arc". You should then have 2 directories with the same contents.
3. Remove all files from SYS:Prefs/Env-Archive except those in SYS:Prefs/Env-Archive/sys and SYS:Prefs/Env-Archive/usb. Do not delete any directories; only files. The directory structure must remain intact.
4. Add the line "Assign ENVARC: SYS:Prefs/env-arc" beneath the line "Failat 21" in the startup-sequence.
5. Reboot into the partition you just changed but don't start any programs.
6. Check the size of ENV: by entering info ENV: and you will see that it is much smaller than it is if you boot from a normal OS4 partition.
7. List the files in the ENV:MUI directory (with list ENV:MUI in a shell) and it should be empty (unless you have MUI programs in your WBStartup).
8. Start IBrowse and list the files in ENV:MUI again. You should now see the files IBROWSE.prefs, Global.prefs and possibly others.
9. You can start other programs that store their prefs and variables in ENV: and they will appear there even though they were not there after booting.

That's how ENV: is supposed to work. Only variables that have been accessed should be there. I think that the reason all the variables/prefs are copied in a current OS4 boot is because there was a problem in OS4 prereleases with some programs that couldn't manipulate their variables/prefs; probably because they weren't doing it the right way. I think the "quick and dirty" solution was to have all the ENVARC: files copied to ENV: during a boot. That's speculation on my part but whatever the reason, it needs to be changed to work the way it's should.

A simpler way to demonstrate how ENV: is supposed to work is to simply delete some prefs before starting a program and watch them reappear in ENV: when the program is started. For example, your can delete ENV:MUI/IBrowse.prefs before starting IBrowse and ENV:MUI/IBrowse.prefs will reappear after the program is started. The IBrowse prefs don't need to be copied to ENV: at boot but they are; along with all the other ENVARC: files except the deficons.

If you guys try any of the above demonstrations and still don't get it, then go to the WEB page of the author of the OS3 & OS4 version of env-handler, Stephan Rupprecht, and read the docs included in the env-handler archive. It states and I quote:

-quote-
The advantages of env-handler over RAM:Env are:

- low memory usage
- faster access to env variables
- a "delete ram:#? all" doesn't hurt ENV vars.
- faster booting (no need to copy envarc: to env:)
-unquote-

Do you get it? NO NEED TO COPY ENVARC: TO ENV:
Whether all the ENVARC: files are being copied during bootup or whether some stupid Linux port is scanning every single variable in the system causing them all to be copied to ENV:, the point is that it shouldn't be happening.