Welcome, Guest. Please login or register.

Author Topic: Layers.library V45 on the aminet  (Read 128989 times)

Description:

0 Members and 6 Guests are viewing this topic.

Offline modrobert

  • Newbie
  • *
  • Join Date: Nov 2008
  • Posts: 47
  • Country: th
    • Show all replies
Re: Layers.library V45 on the aminet
« Reply #14 from previous page: September 14, 2014, 08:16:53 PM »
Quote from: olsen;772983
All versions (1.x through 3.x) are written in a mix of 'C' and 68k assembly language, strongly leaning towards 68k assembly code. Looking at the API, you'll find that a large part of the operations are about filling in data structures, hooking them up and then eventually telling the hardware what to do with them. Typically, the "clerical operations" are written in 'C', and the part which talks to the hardware is written in assembly language.

graphics.library, like intuition.library, is one of the more complex operating system components, both in how it uses data structures and how many distinct operations it can carry out. Hence, you'll find that 'C' plays a major part in its implementation.

Thanks for the explanation.

Quote from: olsen;772983
That said, when you need to talk to the hardware in a very specific manner, you couldn't do that quite so elegantly back in 1986 if you didn't use 68k assembly language. There is complex assembly language code in graphics.library, it even uses its own preprocessor (!) in order to simplify writing loops (while .. do) and control structures (if .. then .. else).

Yes, I assume those are the "macros" Thomas Richter mentioned in his post.


Quote
If you have specific requirements for carrying out operations, you may get better control through the use of assembly language than any modern 'C' compiler could provide you with. C11 has just gained new control keywords in order to make interfacing to hardware more straightforward, but it will take a while for the language to evolve to give you the kind of control only assembly language can give you.

As for assembly language becoming largely redundant, it's probably unavoidable. 'C' in particular is a more expressive language which encodes in fewer lines what assembly language, by its very nature, requires much more effort to express. The thing is, if you can say the same thing with fewer words, the chances of mucking it up are somewhat reduced. If you have the right language, you can even verify the correctness of the instructions and data structures you used, which is something that eludes assembly language by its very design.

As for inefficient code, performance nowadays does not necessarily come out of implementing an algorithm through the optimum low level language encoding you could choose (that being assembly language). You can't necessarily predict how your code will be executed, and if you can, you might have to run the gauntlet of observing a handful of operating conditions under which it executes, such as regarding optimum pipeline use, prefetch, etc. This can get so ugly that it has to be automated (look up how one programmed the Motorola 56000 DSP in its day, just to get an idea how weird this can get) just to let the programmer worry about implementing his design correctly.

This is how progress looks like: the gains made through building faster processors are used in such a way that writing more complex software, more secure software and more reliable software becomes an easier goal to achieve through the use of tools and code generation which does not necessarily attempt to squeeze the last cycle out of the machine. This is, in the end a trade-off, if not a sacrifice.

I agree with this when it comes to modern multi-core CPUs, and especially recent APU architectures. A nightmare to interact with on the low level, way too many opcodes (which look ugly when disassembled...hehe), huge integrated caches to make up for slow external buses, and the die photos looking more like a small city than a CPU.

Thankfully, some of us still have 68k to play with, which is one of the best places to enjoy assembler IMHO.

For me the Amiga is a fun hobby, and since I don't rely on it much for productivity these days, it's all about testing old (and some new) software, trying to code my own programs, playing classic games, and experimenting, even with the hardware building interfaces, coding VHDL and such. The A1200 is my main computer in the electronics lab (that's what I call my little shed with a soldering iron) these days, with proper 25-pin serial interface, parallel port, and mainly TTL signals to play with on the board, it's just great.
« Last Edit: September 14, 2014, 08:32:49 PM by modrobert »
A1200: 68020 @ 14 MHz (stock), 2MB Chip + 8MB Fast RAM, RTC, 3.1 ROMs, IDE-CF+4GB, WiFi WPA2/AES, AmigaOS 3.1, LCD 23" via composhite - Thanks fitzsteve & PorkLip!
 

Offline modrobert

  • Newbie
  • *
  • Join Date: Nov 2008
  • Posts: 47
  • Country: th
    • Show all replies
Re: Layers.library V45 on the aminet
« Reply #15 on: September 15, 2014, 02:50:38 PM »
Quote from: OlafS3;773056
I understand :(

it is a pity that the few experienced devs left cannot contribute because of silly contracts from long ago


They can contribute to Aros if a bounty making OS3.1 open source succeeded. This would effectively end the NDA, or did I miss something (again)?

Also, Thomas Richter and olsen have effectively convinced me that binary patching is bad in the current situation, only took like ten posts of explaining to do it (hehe). Still, I can't help liking Cosmos and respect what he does, it goes beyond logical reasoning, so no need to convince me further.
A1200: 68020 @ 14 MHz (stock), 2MB Chip + 8MB Fast RAM, RTC, 3.1 ROMs, IDE-CF+4GB, WiFi WPA2/AES, AmigaOS 3.1, LCD 23" via composhite - Thanks fitzsteve & PorkLip!
 

Offline modrobert

  • Newbie
  • *
  • Join Date: Nov 2008
  • Posts: 47
  • Country: th
    • Show all replies
Re: Layers.library V45 on the aminet
« Reply #16 on: September 19, 2014, 11:33:41 AM »
My advice is to adopt a shameless attitude towards learning in general, all the information is out there on internet these days if you dig deep enough.

Want to learn a new physics theory? Watch a lecture when the professor who won the recent Nobel price for it explains the theory in detail, made freely available as a video by some University or foundation. If there is something he/she is talking about you don't understand, then search and learn about that as well. Just keep trying, give it time, eventually you will learn. After doing this you will start to get your own ideas and think about solutions to problems not yet solved.

Want to learn hardware design? Learn electronics. Read primers and books (PDF) about VHDL/Verilog on internet until your eyes bleed. After a couple of years, when you design your first state machine (simple CPU) and code a little program running on it, all the effort will be worthwhile.

Want to learn software engineering? Learn the basics of a computer language, anything will do, and then, for example, look at the fastest known sorting method. Tweak something in the code, experiment, watch what happens, even if it gets slower, why did it get slower? One morning you might wake up with a tweak idea which makes it slightly faster. The thrill of that might inspire you to write your own sorting method one day.

Want to learn philosophy? Good, it will help you to think out of the box, and come up with new ideas because suddenly abstraction takes you beyond previous borders of comprehension.

Why not learn all of the above? You can do it, don't let anyone make you think otherwise.

Don't worry about a career, don't worry about academia and titles. Instead, use internet and learn for the sake of knowledge which is its own reward. One day, you will have the potential to be more than anyone blindly following the wisdom of others, make your own path, and eventually others will follow you instead.
« Last Edit: September 19, 2014, 11:58:23 AM by modrobert »
A1200: 68020 @ 14 MHz (stock), 2MB Chip + 8MB Fast RAM, RTC, 3.1 ROMs, IDE-CF+4GB, WiFi WPA2/AES, AmigaOS 3.1, LCD 23" via composhite - Thanks fitzsteve & PorkLip!