On Tue, 5 Jan 2021 22:51:12 +0000, gareth evans declaimed the following:
And no published instruction set either?
Consider this (assembly source) structure... (I may have some mistakes in it, as my manuals are hiding in a storage facility).
arg1 data 1 arg2 data 2 retval data 0 ...
bal,15 dostuff data arg1 ;arg1/arg2/retval are the addresses of the data data arg2 data retval ...
dostuff lw,14 *15 ;* is indirect access operator stw,14 param1 ;retrieve and save address of param1 adi,15 1 ;increment link register lw,14 *15 stw,14 param2 adi,15 1 ld,10 *param1 ;access param1 data mw,10 *param2 stw,10 *15 ;save result return value adi,15 1 b *15 ;return from routine param1 data 0 param2 data 0
--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/
Yeah, I didn't mean X, or even rather comically Curses. I meant: WinForms, WPF, Swing as opposed to: Angular or React. Even Asp.Net was much harder than WinForms.
Compiler features do vary: I don't recall seeing LINKAGE section in any version of the ICL 1900 COBOL compilers, which I was using 1968-1977. If LINKAGE sections had been available I'm sure I would have used them and coded subroutines in COBOL, but though our COBOL code regularly called subroutines, these were all written in PLAN (assembler). From 1978 onward I was programming ICL 2900s: 2900 COBOL implemented LINKAGE sections and we made extensive use of them to split large COBOL programs into modules.
After 1984 I wrote very little COBOL, and that was for DEC and MicroFocus compilers. None of these projects used COBOL subroutines: the DEC RDB interface module was language agnostic and so LINKAGE sections weren't needed. The MicroFocus COBOL projects called C functions. COPY books were fairly common on ICL 1900 projects.
The ICL 2900 world used COPY books too, though it implemented them as calls to the Advanced Data Dictionary) rather than as traditional copy libraries, and handled the IDMSX database interactions via a preprocessor that converted pseudo-COBOL statements COBOL programs into COBOL subroutine calls. The IDMSX schema processor converted schema definitions into the COBOL subroutines called by application programs. All quite neat, easy to use, and worked very well.
Curses is purest C - it sits on top of the termcap functions and adds capabilities like pop-up subwindows
Swing (and AWT) are Java graphics packages included in the standard class library, available since at least Java 2. They are fairly high level classes, implementing buttons, menus, scrollable resizable windows etc. as well as a mouse interface.
Depends what the program is: Hello World in Java is 419 bytes (the C version is 19554 bytes and the source is smaller too (21 lines, 147 chars vs 26 lines, 282 chars) and anyway I like the WORA principle
Thats interesting - I've wondered about learning gtk, but so far have always used Java instead: once you grok MVC (message, view, controller) program structure) understand how keyboard and how keyboard and mouse listeners tie in its all pretty straight forward.
Yes, I'd well believe that: if your program is talking direct to the browser its organisation needn't be a lot different to a Java GUI program using the MVC structure:
- Model contains data storage, input parser, and HTML assembly
Its not that bad: everything I've written has run well on 32 bit hardware: in that environment under Linux the limit tends to be the process address space since I never set the swap partition to less that twice physical memory.
In that environment the only time I've seen a Java program have memory problems is one of mine that loads potentially very large documents into a PostgreSQL DB. It pulls in a lot of library code too, including JavaMail, Mstor and the JDBC code needed to talk to PostgreSQL. In all cases failures due to running out of memory were the result of exceeding the -Xmm defined memory space, i.e. nothing to do with JVM or code size because every time that happened, the run was successful after I'd increased -Xmm. IIRC that box had around 500MB of RAM.
Since moving it to a 64-bit system with 4GB RAM and explicitly setting - xmm in the shell script that launches it I haven't hit and OOM problems with it.
This issue is no worse than running a large C++ program with dynamically loaded library code. In fact it might well be better since the JVM uses a JIT compiler to recompile frequently used Java classes to native code and, presumably, discards the P-code as soon as its been replaced by native code.
Similarly, a Swing-based roster editor I wrote to support a club I belong to only occupies 1.3 MB of RAM with a little 4777 duty slots assigned: that's the complete roster of weekend duties over a six month season with
14 duty assignments on each rostered day.
So, bottom line: I've developed and run fairly substantial Java programs on relatively small Linux boxes and never had issues with running out of memory.
The JVM loadable is 18376 bytes, so not exactly huge, but I don't know how much, if any, dynamically loaded support code it drags in. But note that this is smaller than the hello world program when compiled by the current GCC compiler and statically linked.
But, as I said elsewhere a moderate sized graphical Java program (4000 lines of source code, not counting comments) that I wrote using the Swing GUI occupies 1.3 GB after loading a typical working data set (6 6 month- long rosters with 14 rosterable duties per day.
However, I should hardly need to remind you that C and C++ programs aren't always exactly economical when it comes to load size: I remember looking at this a long time back when Borland compilers were still a thing. IIRC 'hello world' in ANSI C compiled to several 10s of Kbytes and the C++ version compiled to 800Kb using the then current version of Borland's finest.
I think you don't seem to have grasped the issue with server side versus client side. The problem with server side is that it needs a page reload to register changes. If on the other hand you download loads of javascript then you can use that to make the page dynamic. Even if you use AJAX that's still some javascript needed to invoke the callback to the server.
So PHP is not equivalent to JavaScript. PHP is fine at interrogating databases and doing a lot of server side stuff, but for popup dialogues and menus that expand you need Javascript.
I once wrote code that downloaded the ENTIRE contents of a company stock a to allow it to be rapidly searched. It was not as big as some website background images....javascript is pretty fast, too.
--
?It is hard to imagine a more stupid decision or more dangerous way of
making decisions than by putting those decisions in the hands of people
Yes, using selectors such as :focus, :checked or :target instead of event handlers such as onfocus() or onchange(), and if you can ignore older browsers.
You can do a certain amount of form validation with pure html/css, but it generally doesn't take long to need *some* javascript, at which point you might as well make your life a bit easier and use it in more places for consistency.
Either your memory is off or this was some site restriction. I did a lot of COBOL on a Sigma 6, and I?m sure I would have remembered this. I?m trying to recall the dates, but the numbers won?t come - mid 70s maybe? We started using BPM/BTM and moved on to UTS when it was released.
not really - unless you consider that e.g. onmouseover() or hover: is not Javascript and even then if you want to unhide some block, you need to be able to address it via the DOM. So you need a getElementbyId(x).style.display='block'; and so on.
Cant see how to do that in css. willing to find out
I cant really write a web page the way I want it without javascript these days. Ok its not a LOT of javascript.
--
?It is hard to imagine a more stupid decision or more dangerous way of
making decisions than by putting those decisions in the hands of people
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.